[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keycloak-dev
Subject:    [keycloak-dev] cors setup simplification?
From:       stian () redhat ! com (Stian Thorgersen)
Date:       2014-05-20 15:39:57
Message-ID: 892618789.11273284.1400600397770.JavaMail.zimbra () redhat ! com
[Download RAW message or body]



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 May, 2014 4:33:28 PM
> Subject: Re: [keycloak-dev] cors setup simplification?
> 
> 
> 
> On 5/20/2014 10:34 AM, Stian Thorgersen wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 20 May, 2014 3:31:47 PM
> > > Subject: Re: [keycloak-dev] cors setup simplification?
> > > 
> > > 
> > > 
> > > On 5/20/2014 10:19 AM, Stian Thorgersen wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Bill Burke" <bburke at redhat.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Tuesday, 20 May, 2014 3:07:52 PM
> > > > > Subject: Re: [keycloak-dev] cors setup simplification?
> > > > > 
> > > > > 
> > > > > 
> > > > > On 5/20/2014 9:33 AM, Stian Thorgersen wrote:
> > > > > > I like the idea of not having to specify the web-origins, but I wonder
> > > > > > if
> > > > > > there are use-cases for having web-origins that can't be calculated
> > > > > > from
> > > > > > the redirect-uris.
> > > > > > 
> > > > > 
> > > > > I just can't see a case for this.  Let's just let users tell us we need
> > > > > this control.  Right now, the web origin is always set to the
> > > > > protocol://hostname of the application or oauth client.
> > > > > 
> > > > > > Also, the web-origins is used by Keycloak's own endpoints. In this case
> > > > > > "Cross-Origin Tokens" doesn't make sense.
> > > > > > 
> > > > > 
> > > > > You're talking about the Account Service correct?  Well, I'm changing
> > > > > that! :)  How you implemented CORS support for the Account Service is
> > > > > not how web-origins were intended to be used.
> > > > > 
> > > > > Tokens are created for a specific client (app or oauth).  The
> > > > > web-origins for that issuedFor client are stuffed into the token created
> > > > > specifically for that client.  Basically, its saying this token is
> > > > > allowed to come from this set of origins.
> > > > > 
> > > > > What Web-Origins are not origin permissions for that application/client.
> > > > > When you specify a web origin for the Account Service (or any other
> > > > > application) in the admin console, this is not origins that are allowed
> > > > > to call the account service!  But instead, the origins allowed for token
> > > > > requests made from tokens created for the Account Service.  Am I making
> > > > > sense?
> > > > 
> > > > Yep, it makes more sense for the account service that way. I was thinking
> > > > about token service though, both code->token and refresh-token are called
> > > > from JS and need web-origins configured on them.
> > > > 
> > > 
> > > All the token service is doing is verifying that a code->token
> > > refresh-token request for that client is coming from the configured
> > > origin of that client.
> > > 
> > > Ah, I think I have a better explanation. The Web-Origin setting for an
> > > application is just the Origin of the application.  Nothing else.
> > 
> > The origin of the application making the request right?
> > 
> 
> Nothing to do with the request.  It is just the origin of the application.

By application making the request I meant the JS application/client (the public \
application), which is the application that will be making the request correct?


> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 


[prev in list] [next in list] [prev in thread] [next in thread]