8:10 a.m.
CORS setup is confusing to people. I'm going to remove the web-origins
setting from the admin console. Instead there will be a on/off switch
that says "Cross-Origin Tokens (CORS)". Tokens created for those types
of clients will have the token's origins calculated by iterating over
the redirect uri list.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:33 a.m.
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.
Also, the web-origins is used by Keycloak's own endpoints. In this case
"Cross-Origin Tokens" doesn't make sense.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 20 May, 2014 2:10:45 PM
Subject: [keycloak-dev] cors setup simplification?
CORS setup is confusing to people. I'm going to remove the web-origins
setting from the admin console. Instead there will be a on/off switch
that says "Cross-Origin Tokens (CORS)". Tokens created for those types
of clients will have the token's origins calculated by iterating over
the redirect uri list.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:07 a.m.
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?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:19 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:31 a.m.
On 5/20/2014 10:19 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:34 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)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?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:33 a.m.
On 5/20/2014 10:34 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:39 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>> Cc: keycloak-dev(a)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
9:19 a.m.
On 5/20/2014 10:07 AM, Bill Burke wrote:
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?
Ugh, let me reword last paragraph:
Web-origin setting is not a set of origin permissions for an
applicatin/client. For example, the account service's web-origin
setting is not the origins that are allowed to call the account service!
Tokens are always created for a specific client (issuedFor). The
client's web origin setting is just information that is stuffed into the
token when it is created.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:22 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 20 May, 2014 3:19:56 PM
Subject: Re: [keycloak-dev] cors setup simplification?
On 5/20/2014 10:07 AM, Bill Burke wrote:
>
>
> 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?
>
Ugh, let me reword last paragraph:
Web-origin setting is not a set of origin permissions for an
applicatin/client. For example, the account service's web-origin
setting is not the origins that are allowed to call the account service!
Tokens are always created for a specific client (issuedFor). The
client's web origin setting is just information that is stuffed into the
token when it is created.
The account service does use the clients web-origins atm, it just pulls it from the
ClientModel instead of the token, or at least that was the intent ;)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3868
days inactive
3868
days old
9 comments
2 participants
participants (2)
-
Bill Burke -
Stian Thorgersen