Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Ishara Karunarathna]

On Sun, May 14, 2017 at 12:54 PM, Nuwan Dias  wrote:

> Ok. All of these are extensions anyway. If some IDP sends the same
> responses as IS the benefit is that we can just plug and play. If there are
> differences we basically have to write code and deploy as extensions.
>
Yes this implementations can be differ fom IDP to IDP.
So better to do the default implementation with IS and keep extension for
other implementations

>
> On Sun, 14 May 2017 at 12:44 pm, Farasath Ahamed 
> wrote:
>
>> On Sun, May 14, 2017 at 12:30 PM, Nuwan Dias  wrote:
>>
>>> It looks like we may have to use the introspect to validate the token
>>> and use a proprietary api in IS to get user claims.
>>>
>>
>> Sending username of the authorized user in the introspection response is
>> not mandatory. IS sends by default. This may not be the same with external
>> Key Managers. So we might have to consider that as well.
>>
>>
>>> When using an external KM we will have to override the part that gets
>>> user claims. That's of course if they want to send JWT to target endpoints
>>> only.
>>>
>>> On Sun, 14 May 2017 at 8:57 am, Bhathiya Jayasekara 
>>> wrote:
>>>
 Hi Ishara,

 On Sun, May 14, 2017 at 8:51 AM, Ishara Karunarathna 
 wrote:

> Hi,
>
> On Sun, May 14, 2017 at 8:42 AM, Ishara Karunarathna  > wrote:
>
>> Hi Bhathiya,
>>
>> On Sun, May 14, 2017 at 8:18 AM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> Hi Ishara,
>>>
>>> On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna <
>>> isha...@wso2.com> wrote:
>>>
 Hi,

 In the current implementations you get a JWT token from token
 validation service regardless of the grant types.
 But this would be a problem when you go with standards only. For
 example you may not be able to get and ID token from IDP if its only
 supporting specifications.

>>>
>>> We thought of using "openid" scope when generating token and then
>>> call userinfo after validating (introspect) the token. I expect that 
>>> should
>>> work if the IDP is complient with the specs. WDYT?
>>>
>> What I'm saying is for all the oauth grant types does not work with
>> OIDC
>> For example in password grant type you can't use OIDC. OIDC define
>> only authorization code and implicit grant types (it has a hybrid flow as
>> well )
>> In that case you can't expect to get ID token for all grant types.
>>
>
 Oh that's going to be a problem.


> So do you need this user information in all the cases ??
>

 Yes we may need, specially in passwrod grant type. If this is not going
 to work, we will have to think of a different solution (like the SCIM one
 you suggested.)

 Thanks,
 Bhathiya


>
> one option that come to my mind is.
> in the token introspection response get the user name.
> And then call a SCIM endpoint (or any other api to get the user
> information) to get user information.
>
> But this also has a issue, this username is a optional parameter
>
>
>>
>> So do you need this user information in all the cases ??
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>

 so this has to be address case by case.
 -Ishara

 On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara <
 bhath...@wso2.com> wrote:

> Thanks for the explanation Farasath.
>
> So this means we have to do a DCR call and another service call to
> register claims to SP. @Tharindu: looks like we don't have a choice 
> here.
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed <
> farasa...@wso2.com> wrote:
>
>>
>> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> Hi Farasath,
>>>
>>> That's going to be a problem when we use DCR, I guess. Shouldn't
>>> we send the claims given in the spec for each scope by default, 
>>> without any
>>> special configurations in SP?
>>>
>>
>> Not really.
>>
>> Even the spec says[1],
>>
>> In some cases, the End-User will be given the option to have the
>>> OpenID Provider decline to provide some or all information 
>>> requested by
>>> RPs. To minimize the amount of information that the End-User is 
>>> being asked
>>> to disclose, an RP can elect to only request a subset of the 
>>> information
>>> available from the UserInfo Endpoint.
>>
>>
>> Simply put we are not bound to provide all 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Nuwan Dias]

Ok. All of these are extensions anyway. If some IDP sends the same
responses as IS the benefit is that we can just plug and play. If there are
differences we basically have to write code and deploy as extensions.

On Sun, 14 May 2017 at 12:44 pm, Farasath Ahamed  wrote:

> On Sun, May 14, 2017 at 12:30 PM, Nuwan Dias  wrote:
>
>> It looks like we may have to use the introspect to validate the token and
>> use a proprietary api in IS to get user claims.
>>
>
> Sending username of the authorized user in the introspection response is
> not mandatory. IS sends by default. This may not be the same with external
> Key Managers. So we might have to consider that as well.
>
>
>> When using an external KM we will have to override the part that gets
>> user claims. That's of course if they want to send JWT to target endpoints
>> only.
>>
>> On Sun, 14 May 2017 at 8:57 am, Bhathiya Jayasekara 
>> wrote:
>>
>>> Hi Ishara,
>>>
>>> On Sun, May 14, 2017 at 8:51 AM, Ishara Karunarathna 
>>> wrote:
>>>
 Hi,

 On Sun, May 14, 2017 at 8:42 AM, Ishara Karunarathna 
 wrote:

> Hi Bhathiya,
>
> On Sun, May 14, 2017 at 8:18 AM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Hi Ishara,
>>
>> On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna <
>> isha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> In the current implementations you get a JWT token from token
>>> validation service regardless of the grant types.
>>> But this would be a problem when you go with standards only. For
>>> example you may not be able to get and ID token from IDP if its only
>>> supporting specifications.
>>>
>>
>> We thought of using "openid" scope when generating token and then
>> call userinfo after validating (introspect) the token. I expect that 
>> should
>> work if the IDP is complient with the specs. WDYT?
>>
> What I'm saying is for all the oauth grant types does not work with
> OIDC
> For example in password grant type you can't use OIDC. OIDC define
> only authorization code and implicit grant types (it has a hybrid flow as
> well )
> In that case you can't expect to get ID token for all grant types.
>

>>> Oh that's going to be a problem.
>>>
>>>
 So do you need this user information in all the cases ??

>>>
>>> Yes we may need, specially in passwrod grant type. If this is not going
>>> to work, we will have to think of a different solution (like the SCIM one
>>> you suggested.)
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>>

 one option that come to my mind is.
 in the token introspection response get the user name.
 And then call a SCIM endpoint (or any other api to get the user
 information) to get user information.

 But this also has a issue, this username is a optional parameter


>
> So do you need this user information in all the cases ??
>
>
>> Thanks,
>> Bhathiya
>>
>>
>>>
>>> so this has to be address case by case.
>>> -Ishara
>>>
>>> On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara <
>>> bhath...@wso2.com> wrote:
>>>
 Thanks for the explanation Farasath.

 So this means we have to do a DCR call and another service call to
 register claims to SP. @Tharindu: looks like we don't have a choice 
 here.

 Thanks,
 Bhathiya

 On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed <
 farasa...@wso2.com> wrote:

>
> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Hi Farasath,
>>
>> That's going to be a problem when we use DCR, I guess. Shouldn't
>> we send the claims given in the spec for each scope by default, 
>> without any
>> special configurations in SP?
>>
>
> Not really.
>
> Even the spec says[1],
>
> In some cases, the End-User will be given the option to have the
>> OpenID Provider decline to provide some or all information requested 
>> by
>> RPs. To minimize the amount of information that the End-User is 
>> being asked
>> to disclose, an RP can elect to only request a subset of the 
>> information
>> available from the UserInfo Endpoint.
>
>
> Simply put we are not bound to provide all the claims a
> client(Relying party) asks for using a 'scope'. There should be a way 
> to
> control the claims that are sent out based on the application. This is
> because the sensitive nature of a claim depends on the application and
> other factors as well. For example, 'phone number' might be a 
> sensitive
> 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Farasath Ahamed]

On Sun, May 14, 2017 at 12:30 PM, Nuwan Dias  wrote:

> It looks like we may have to use the introspect to validate the token and
> use a proprietary api in IS to get user claims.
>

Sending username of the authorized user in the introspection response is
not mandatory. IS sends by default. This may not be the same with external
Key Managers. So we might have to consider that as well.


> When using an external KM we will have to override the part that gets user
> claims. That's of course if they want to send JWT to target endpoints only.
>
> On Sun, 14 May 2017 at 8:57 am, Bhathiya Jayasekara 
> wrote:
>
>> Hi Ishara,
>>
>> On Sun, May 14, 2017 at 8:51 AM, Ishara Karunarathna 
>> wrote:
>>
>>> Hi,
>>>
>>> On Sun, May 14, 2017 at 8:42 AM, Ishara Karunarathna 
>>> wrote:
>>>
 Hi Bhathiya,

 On Sun, May 14, 2017 at 8:18 AM, Bhathiya Jayasekara  wrote:

> Hi Ishara,
>
> On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna  > wrote:
>
>> Hi,
>>
>> In the current implementations you get a JWT token from token
>> validation service regardless of the grant types.
>> But this would be a problem when you go with standards only. For
>> example you may not be able to get and ID token from IDP if its only
>> supporting specifications.
>>
>
> We thought of using "openid" scope when generating token and then call
> userinfo after validating (introspect) the token. I expect that should 
> work
> if the IDP is complient with the specs. WDYT?
>
 What I'm saying is for all the oauth grant types does not work with OIDC
 For example in password grant type you can't use OIDC. OIDC define only
 authorization code and implicit grant types (it has a hybrid flow as well )
 In that case you can't expect to get ID token for all grant types.

>>>
>> Oh that's going to be a problem.
>>
>>
>>> So do you need this user information in all the cases ??
>>>
>>
>> Yes we may need, specially in passwrod grant type. If this is not going
>> to work, we will have to think of a different solution (like the SCIM one
>> you suggested.)
>>
>> Thanks,
>> Bhathiya
>>
>>
>>>
>>> one option that come to my mind is.
>>> in the token introspection response get the user name.
>>> And then call a SCIM endpoint (or any other api to get the user
>>> information) to get user information.
>>>
>>> But this also has a issue, this username is a optional parameter
>>>
>>>

 So do you need this user information in all the cases ??


> Thanks,
> Bhathiya
>
>
>>
>> so this has to be address case by case.
>> -Ishara
>>
>> On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> Thanks for the explanation Farasath.
>>>
>>> So this means we have to do a DCR call and another service call to
>>> register claims to SP. @Tharindu: looks like we don't have a choice 
>>> here.
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed >> > wrote:
>>>

 On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara <
 bhath...@wso2.com> wrote:

> Hi Farasath,
>
> That's going to be a problem when we use DCR, I guess. Shouldn't
> we send the claims given in the spec for each scope by default, 
> without any
> special configurations in SP?
>

 Not really.

 Even the spec says[1],

 In some cases, the End-User will be given the option to have the
> OpenID Provider decline to provide some or all information requested 
> by
> RPs. To minimize the amount of information that the End-User is being 
> asked
> to disclose, an RP can elect to only request a subset of the 
> information
> available from the UserInfo Endpoint.


 Simply put we are not bound to provide all the claims a
 client(Relying party) asks for using a 'scope'. There should be a way 
 to
 control the claims that are sent out based on the application. This is
 because the sensitive nature of a claim depends on the application and
 other factors as well. For example, 'phone number' might be a sensitive
 claim for some apps. Therefore for such apps, we need to have a  way to
 control a client from getting hold of that claim using scope 'phone'.

 So we can consider "requested claims" in Service Provider config as
 our way of allowing an application admin to decide what claims an 
 external
 client can retrieve and what not.

 [1] http://openid.net/specs/openid-connect-core-1_0.html#
 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Nuwan Dias]

It looks like we may have to use the introspect to validate the token and
use a proprietary api in IS to get user claims.

When using an external KM we will have to override the part that gets user
claims. That's of course if they want to send JWT to target endpoints only.

On Sun, 14 May 2017 at 8:57 am, Bhathiya Jayasekara 
wrote:

> Hi Ishara,
>
> On Sun, May 14, 2017 at 8:51 AM, Ishara Karunarathna 
> wrote:
>
>> Hi,
>>
>> On Sun, May 14, 2017 at 8:42 AM, Ishara Karunarathna 
>> wrote:
>>
>>> Hi Bhathiya,
>>>
>>> On Sun, May 14, 2017 at 8:18 AM, Bhathiya Jayasekara 
>>> wrote:
>>>
 Hi Ishara,

 On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna 
 wrote:

> Hi,
>
> In the current implementations you get a JWT token from token
> validation service regardless of the grant types.
> But this would be a problem when you go with standards only. For
> example you may not be able to get and ID token from IDP if its only
> supporting specifications.
>

 We thought of using "openid" scope when generating token and then call
 userinfo after validating (introspect) the token. I expect that should work
 if the IDP is complient with the specs. WDYT?

>>> What I'm saying is for all the oauth grant types does not work with OIDC
>>> For example in password grant type you can't use OIDC. OIDC define only
>>> authorization code and implicit grant types (it has a hybrid flow as well )
>>> In that case you can't expect to get ID token for all grant types.
>>>
>>
> Oh that's going to be a problem.
>
>
>> So do you need this user information in all the cases ??
>>
>
> Yes we may need, specially in passwrod grant type. If this is not going to
> work, we will have to think of a different solution (like the SCIM one you
> suggested.)
>
> Thanks,
> Bhathiya
>
>
>>
>> one option that come to my mind is.
>> in the token introspection response get the user name.
>> And then call a SCIM endpoint (or any other api to get the user
>> information) to get user information.
>>
>> But this also has a issue, this username is a optional parameter
>>
>>
>>>
>>> So do you need this user information in all the cases ??
>>>
>>>
 Thanks,
 Bhathiya


>
> so this has to be address case by case.
> -Ishara
>
> On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Thanks for the explanation Farasath.
>>
>> So this means we have to do a DCR call and another service call to
>> register claims to SP. @Tharindu: looks like we don't have a choice here.
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara <
>>> bhath...@wso2.com> wrote:
>>>
 Hi Farasath,

 That's going to be a problem when we use DCR, I guess. Shouldn't we
 send the claims given in the spec for each scope by default, without 
 any
 special configurations in SP?

>>>
>>> Not really.
>>>
>>> Even the spec says[1],
>>>
>>> In some cases, the End-User will be given the option to have the
 OpenID Provider decline to provide some or all information requested by
 RPs. To minimize the amount of information that the End-User is being 
 asked
 to disclose, an RP can elect to only request a subset of the 
 information
 available from the UserInfo Endpoint.
>>>
>>>
>>> Simply put we are not bound to provide all the claims a
>>> client(Relying party) asks for using a 'scope'. There should be a way to
>>> control the claims that are sent out based on the application. This is
>>> because the sensitive nature of a claim depends on the application and
>>> other factors as well. For example, 'phone number' might be a sensitive
>>> claim for some apps. Therefore for such apps, we need to have a  way to
>>> control a client from getting hold of that claim using scope 'phone'.
>>>
>>> So we can consider "requested claims" in Service Provider config as
>>> our way of allowing an application admin to decide what claims an 
>>> external
>>> client can retrieve and what not.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>>
>>>
 Thanks,
 Bhathiya



 On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed <
 farasa...@wso2.com> wrote:

> Hi,
>
> Yes. We do support openid scopes (address, email, phone, profile).
> (Refer [1])
> But as Tharindu has mentioned this too requires the relevant
> claims that fall under these scopes to be configured as requested 
> 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Bhathiya Jayasekara]

Hi Ishara,

On Sun, May 14, 2017 at 8:51 AM, Ishara Karunarathna 
wrote:

> Hi,
>
> On Sun, May 14, 2017 at 8:42 AM, Ishara Karunarathna 
> wrote:
>
>> Hi Bhathiya,
>>
>> On Sun, May 14, 2017 at 8:18 AM, Bhathiya Jayasekara 
>> wrote:
>>
>>> Hi Ishara,
>>>
>>> On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna 
>>> wrote:
>>>
 Hi,

 In the current implementations you get a JWT token from token
 validation service regardless of the grant types.
 But this would be a problem when you go with standards only. For
 example you may not be able to get and ID token from IDP if its only
 supporting specifications.

>>>
>>> We thought of using "openid" scope when generating token and then call
>>> userinfo after validating (introspect) the token. I expect that should work
>>> if the IDP is complient with the specs. WDYT?
>>>
>> What I'm saying is for all the oauth grant types does not work with OIDC
>> For example in password grant type you can't use OIDC. OIDC define only
>> authorization code and implicit grant types (it has a hybrid flow as well )
>> In that case you can't expect to get ID token for all grant types.
>>
>
Oh that's going to be a problem.


> So do you need this user information in all the cases ??
>

Yes we may need, specially in passwrod grant type. If this is not going to
work, we will have to think of a different solution (like the SCIM one you
suggested.)

Thanks,
Bhathiya


>
> one option that come to my mind is.
> in the token introspection response get the user name.
> And then call a SCIM endpoint (or any other api to get the user
> information) to get user information.
>
> But this also has a issue, this username is a optional parameter
>
>
>>
>> So do you need this user information in all the cases ??
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>

 so this has to be address case by case.
 -Ishara

 On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara <
 bhath...@wso2.com> wrote:

> Thanks for the explanation Farasath.
>
> So this means we have to do a DCR call and another service call to
> register claims to SP. @Tharindu: looks like we don't have a choice here.
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
> wrote:
>
>>
>> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> Hi Farasath,
>>>
>>> That's going to be a problem when we use DCR, I guess. Shouldn't we
>>> send the claims given in the spec for each scope by default, without any
>>> special configurations in SP?
>>>
>>
>> Not really.
>>
>> Even the spec says[1],
>>
>> In some cases, the End-User will be given the option to have the
>>> OpenID Provider decline to provide some or all information requested by
>>> RPs. To minimize the amount of information that the End-User is being 
>>> asked
>>> to disclose, an RP can elect to only request a subset of the information
>>> available from the UserInfo Endpoint.
>>
>>
>> Simply put we are not bound to provide all the claims a
>> client(Relying party) asks for using a 'scope'. There should be a way to
>> control the claims that are sent out based on the application. This is
>> because the sensitive nature of a claim depends on the application and
>> other factors as well. For example, 'phone number' might be a sensitive
>> claim for some apps. Therefore for such apps, we need to have a  way to
>> control a client from getting hold of that claim using scope 'phone'.
>>
>> So we can consider "requested claims" in Service Provider config as
>> our way of allowing an application admin to decide what claims an 
>> external
>> client can retrieve and what not.
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
>>>
>>> On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed >> > wrote:
>>>
 Hi,

 Yes. We do support openid scopes (address, email, phone, profile).
 (Refer [1])
 But as Tharindu has mentioned this too requires the relevant claims
 that fall under these scopes to be configured as requested claims in 
 the
 Service Provider.

 For example,
 OIDC scope 'address' would return "address" and "street" claims.
 But unless you have these claims as requested claims in the claim
 configuration of the SP. These claims won't be returned although you
 requested the token with a scope value of "openid address"

 The idea here is Service Provider requested claims takes priority
 over claims defined for scopes.


 [1] 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Ishara Karunarathna]

Hi,

On Sun, May 14, 2017 at 8:42 AM, Ishara Karunarathna 
wrote:

> Hi Bhathiya,
>
> On Sun, May 14, 2017 at 8:18 AM, Bhathiya Jayasekara 
> wrote:
>
>> Hi Ishara,
>>
>> On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna 
>> wrote:
>>
>>> Hi,
>>>
>>> In the current implementations you get a JWT token from token validation
>>> service regardless of the grant types.
>>> But this would be a problem when you go with standards only. For example
>>> you may not be able to get and ID token from IDP if its only supporting
>>> specifications.
>>>
>>
>> We thought of using "openid" scope when generating token and then call
>> userinfo after validating (introspect) the token. I expect that should work
>> if the IDP is complient with the specs. WDYT?
>>
> What I'm saying is for all the oauth grant types does not work with OIDC
> For example in password grant type you can't use OIDC. OIDC define only
> authorization code and implicit grant types (it has a hybrid flow as well )
> In that case you can't expect to get ID token for all grant types.
>

one option that come to my mind is.
in the token introspection response get the user name.
And then call a SCIM endpoint (or any other api to get the user
information) to get user information.

But this also has a issue, this username is a optional parameter


>
> So do you need this user information in all the cases ??
>
>
>> Thanks,
>> Bhathiya
>>
>>
>>>
>>> so this has to be address case by case.
>>> -Ishara
>>>
>>> On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara >> > wrote:
>>>
 Thanks for the explanation Farasath.

 So this means we have to do a DCR call and another service call to
 register claims to SP. @Tharindu: looks like we don't have a choice here.

 Thanks,
 Bhathiya

 On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
 wrote:

>
> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Hi Farasath,
>>
>> That's going to be a problem when we use DCR, I guess. Shouldn't we
>> send the claims given in the spec for each scope by default, without any
>> special configurations in SP?
>>
>
> Not really.
>
> Even the spec says[1],
>
> In some cases, the End-User will be given the option to have the
>> OpenID Provider decline to provide some or all information requested by
>> RPs. To minimize the amount of information that the End-User is being 
>> asked
>> to disclose, an RP can elect to only request a subset of the information
>> available from the UserInfo Endpoint.
>
>
> Simply put we are not bound to provide all the claims a client(Relying
> party) asks for using a 'scope'. There should be a way to control the
> claims that are sent out based on the application. This is because the
> sensitive nature of a claim depends on the application and other factors 
> as
> well. For example, 'phone number' might be a sensitive claim for some 
> apps.
> Therefore for such apps, we need to have a  way to control a client from
> getting hold of that claim using scope 'phone'.
>
> So we can consider "requested claims" in Service Provider config as
> our way of allowing an application admin to decide what claims an external
> client can retrieve and what not.
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>
>
>> Thanks,
>> Bhathiya
>>
>>
>>
>> On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
>> wrote:
>>
>>> Hi,
>>>
>>> Yes. We do support openid scopes (address, email, phone, profile).
>>> (Refer [1])
>>> But as Tharindu has mentioned this too requires the relevant claims
>>> that fall under these scopes to be configured as requested claims in the
>>> Service Provider.
>>>
>>> For example,
>>> OIDC scope 'address' would return "address" and "street" claims. But
>>> unless you have these claims as requested claims in the claim 
>>> configuration
>>> of the SP. These claims won't be returned although you requested the 
>>> token
>>> with a scope value of "openid address"
>>>
>>> The idea here is Service Provider requested claims takes priority
>>> over claims defined for scopes.
>>>
>>>
>>> [1] https://docs.wso2.com/display/IS530/Configuring+Claims+f
>>> or+a+Service+Provider (Click to view vital information when
>>> configuring claims for an OpenID Connect Service Provider)
>>>
>>>
>>> Thanks,
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>> On Sat, 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Bhathiya Jayasekara]

Hi Gayan,

On Sun, May 14, 2017 at 8:08 AM, Gayan Gunawardana  wrote:

>
>
> On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara 
> wrote:
>
>> Thanks for the explanation Farasath.
>>
>> So this means we have to do a DCR call and another service call to
>> register claims to SP. @Tharindu: looks like we don't have a choice here.
>>
> Hi Bathiya,
> "Requested Claim" is a feature which is specific to WSO2 Identity Server.
> You may not find such a feature in all Identity Providers.
>

Yes, but there can be such restrictions in other IDPs too. So this should
be handled in each KM implementation.


> Better to think about third party key managers as well.
> In your case is it required to put all user claims in JWT or set of claims
> define in some configuration ?
>
> Apart from Scopes you can even use [1],[2] to request claims.
>

Thanks for the information. But we still need to register those claims to
SP as Farasath mentioned, I assume. Am I correct?

Thanks,
Bhathiya


>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>
> [2] http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
>
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara 
>>> wrote:
>>>
 Hi Farasath,

 That's going to be a problem when we use DCR, I guess. Shouldn't we
 send the claims given in the spec for each scope by default, without any
 special configurations in SP?

>>>
>>> Not really.
>>>
>>> Even the spec says[1],
>>>
>>> In some cases, the End-User will be given the option to have the OpenID
 Provider decline to provide some or all information requested by RPs. To
 minimize the amount of information that the End-User is being asked to
 disclose, an RP can elect to only request a subset of the information
 available from the UserInfo Endpoint.
>>>
>>>
>>> Simply put we are not bound to provide all the claims a client(Relying
>>> party) asks for using a 'scope'. There should be a way to control the
>>> claims that are sent out based on the application. This is because the
>>> sensitive nature of a claim depends on the application and other factors as
>>> well. For example, 'phone number' might be a sensitive claim for some apps.
>>> Therefore for such apps, we need to have a  way to control a client from
>>> getting hold of that claim using scope 'phone'.
>>>
>>> So we can consider "requested claims" in Service Provider config as our
>>> way of allowing an application admin to decide what claims an external
>>> client can retrieve and what not.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>>
>>>
 Thanks,
 Bhathiya



 On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
 wrote:

> Hi,
>
> Yes. We do support openid scopes (address, email, phone, profile).
> (Refer [1])
> But as Tharindu has mentioned this too requires the relevant claims
> that fall under these scopes to be configured as requested claims in the
> Service Provider.
>
> For example,
> OIDC scope 'address' would return "address" and "street" claims. But
> unless you have these claims as requested claims in the claim 
> configuration
> of the SP. These claims won't be returned although you requested the token
> with a scope value of "openid address"
>
> The idea here is Service Provider requested claims takes priority over
> claims defined for scopes.
>
>
> [1] https://docs.wso2.com/display/IS530/Configuring+Claims+f
> or+a+Service+Provider (Click to view vital information when
> configuring claims for an OpenID Connect Service Provider)
>
>
> Thanks,
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
> On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> @IS team: Do we support these in our current implementation?
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> Hi Tharindu,
>>>
>>> In OIDC there are other standard scopes[1] in addition to 'openid'.
>>> These scopes are there to request specific user claims. I think we can 
>>> use
>>> them here. So when generating tokens, these scopes should be used as per
>>> the requirement.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Ishara Karunarathna]

Hi Bhathiya,

On Sun, May 14, 2017 at 8:18 AM, Bhathiya Jayasekara 
wrote:

> Hi Ishara,
>
> On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna 
> wrote:
>
>> Hi,
>>
>> In the current implementations you get a JWT token from token validation
>> service regardless of the grant types.
>> But this would be a problem when you go with standards only. For example
>> you may not be able to get and ID token from IDP if its only supporting
>> specifications.
>>
>
> We thought of using "openid" scope when generating token and then call
> userinfo after validating (introspect) the token. I expect that should work
> if the IDP is complient with the specs. WDYT?
>
What I'm saying is for all the oauth grant types does not work with OIDC
For example in password grant type you can't use OIDC. OIDC define only
authorization code and implicit grant types (it has a hybrid flow as well )
In that case you can't expect to get ID token for all grant types.

So do you need this user information in all the cases ??


> Thanks,
> Bhathiya
>
>
>>
>> so this has to be address case by case.
>> -Ishara
>>
>> On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara 
>> wrote:
>>
>>> Thanks for the explanation Farasath.
>>>
>>> So this means we have to do a DCR call and another service call to
>>> register claims to SP. @Tharindu: looks like we don't have a choice here.
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
>>> wrote:
>>>

 On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara  wrote:

> Hi Farasath,
>
> That's going to be a problem when we use DCR, I guess. Shouldn't we
> send the claims given in the spec for each scope by default, without any
> special configurations in SP?
>

 Not really.

 Even the spec says[1],

 In some cases, the End-User will be given the option to have the OpenID
> Provider decline to provide some or all information requested by RPs. To
> minimize the amount of information that the End-User is being asked to
> disclose, an RP can elect to only request a subset of the information
> available from the UserInfo Endpoint.


 Simply put we are not bound to provide all the claims a client(Relying
 party) asks for using a 'scope'. There should be a way to control the
 claims that are sent out based on the application. This is because the
 sensitive nature of a claim depends on the application and other factors as
 well. For example, 'phone number' might be a sensitive claim for some apps.
 Therefore for such apps, we need to have a  way to control a client from
 getting hold of that claim using scope 'phone'.

 So we can consider "requested claims" in Service Provider config as our
 way of allowing an application admin to decide what claims an external
 client can retrieve and what not.

 [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims


> Thanks,
> Bhathiya
>
>
>
> On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
> wrote:
>
>> Hi,
>>
>> Yes. We do support openid scopes (address, email, phone, profile).
>> (Refer [1])
>> But as Tharindu has mentioned this too requires the relevant claims
>> that fall under these scopes to be configured as requested claims in the
>> Service Provider.
>>
>> For example,
>> OIDC scope 'address' would return "address" and "street" claims. But
>> unless you have these claims as requested claims in the claim 
>> configuration
>> of the SP. These claims won't be returned although you requested the 
>> token
>> with a scope value of "openid address"
>>
>> The idea here is Service Provider requested claims takes priority
>> over claims defined for scopes.
>>
>>
>> [1] https://docs.wso2.com/display/IS530/Configuring+Claims+f
>> or+a+Service+Provider (Click to view vital information when
>> configuring claims for an OpenID Connect Service Provider)
>>
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>> On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> @IS team: Do we support these in our current implementation?
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara <
>>> bhath...@wso2.com> wrote:
>>>
 Hi Tharindu,

 In OIDC there are other standard scopes[1] in addition to 'openid'.
 These scopes are there to request specific user claims. I think we can 
 use

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Bhathiya Jayasekara]

Hi Ishara,

On Sun, May 14, 2017 at 7:16 AM, Ishara Karunarathna 
wrote:

> Hi,
>
> In the current implementations you get a JWT token from token validation
> service regardless of the grant types.
> But this would be a problem when you go with standards only. For example
> you may not be able to get and ID token from IDP if its only supporting
> specifications.
>

We thought of using "openid" scope when generating token and then call
userinfo after validating (introspect) the token. I expect that should work
if the IDP is complient with the specs. WDYT?

Thanks,
Bhathiya


>
> so this has to be address case by case.
> -Ishara
>
> On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara 
> wrote:
>
>> Thanks for the explanation Farasath.
>>
>> So this means we have to do a DCR call and another service call to
>> register claims to SP. @Tharindu: looks like we don't have a choice here.
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara 
>>> wrote:
>>>
 Hi Farasath,

 That's going to be a problem when we use DCR, I guess. Shouldn't we
 send the claims given in the spec for each scope by default, without any
 special configurations in SP?

>>>
>>> Not really.
>>>
>>> Even the spec says[1],
>>>
>>> In some cases, the End-User will be given the option to have the OpenID
 Provider decline to provide some or all information requested by RPs. To
 minimize the amount of information that the End-User is being asked to
 disclose, an RP can elect to only request a subset of the information
 available from the UserInfo Endpoint.
>>>
>>>
>>> Simply put we are not bound to provide all the claims a client(Relying
>>> party) asks for using a 'scope'. There should be a way to control the
>>> claims that are sent out based on the application. This is because the
>>> sensitive nature of a claim depends on the application and other factors as
>>> well. For example, 'phone number' might be a sensitive claim for some apps.
>>> Therefore for such apps, we need to have a  way to control a client from
>>> getting hold of that claim using scope 'phone'.
>>>
>>> So we can consider "requested claims" in Service Provider config as our
>>> way of allowing an application admin to decide what claims an external
>>> client can retrieve and what not.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>>
>>>
 Thanks,
 Bhathiya



 On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
 wrote:

> Hi,
>
> Yes. We do support openid scopes (address, email, phone, profile).
> (Refer [1])
> But as Tharindu has mentioned this too requires the relevant claims
> that fall under these scopes to be configured as requested claims in the
> Service Provider.
>
> For example,
> OIDC scope 'address' would return "address" and "street" claims. But
> unless you have these claims as requested claims in the claim 
> configuration
> of the SP. These claims won't be returned although you requested the token
> with a scope value of "openid address"
>
> The idea here is Service Provider requested claims takes priority over
> claims defined for scopes.
>
>
> [1] https://docs.wso2.com/display/IS530/Configuring+Claims+f
> or+a+Service+Provider (Click to view vital information when
> configuring claims for an OpenID Connect Service Provider)
>
>
> Thanks,
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
> On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> @IS team: Do we support these in our current implementation?
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> Hi Tharindu,
>>>
>>> In OIDC there are other standard scopes[1] in addition to 'openid'.
>>> These scopes are there to request specific user claims. I think we can 
>>> use
>>> them here. So when generating tokens, these scopes should be used as per
>>> the requirement.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 Hi All,

 We had a use case on APIM to send the user claims in the JWT Header
 to the backend server.

 Currently APIM C4 architecture was Getting the user claims and
 generate JWT from Key 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Gayan Gunawardana]

On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara 
wrote:

> Thanks for the explanation Farasath.
>
> So this means we have to do a DCR call and another service call to
> register claims to SP. @Tharindu: looks like we don't have a choice here.
>
Hi Bathiya,
"Requested Claim" is a feature which is specific to WSO2 Identity Server.
You may not find such a feature in all Identity Providers. Better to think
about third party key managers as well.
In your case is it required to put all user claims in JWT or set of claims
define in some configuration ?

Apart from Scopes you can even use [1],[2] to request claims.

[1] http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests

[2] http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
> wrote:
>
>>
>> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara 
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> That's going to be a problem when we use DCR, I guess. Shouldn't we send
>>> the claims given in the spec for each scope by default, without any special
>>> configurations in SP?
>>>
>>
>> Not really.
>>
>> Even the spec says[1],
>>
>> In some cases, the End-User will be given the option to have the OpenID
>>> Provider decline to provide some or all information requested by RPs. To
>>> minimize the amount of information that the End-User is being asked to
>>> disclose, an RP can elect to only request a subset of the information
>>> available from the UserInfo Endpoint.
>>
>>
>> Simply put we are not bound to provide all the claims a client(Relying
>> party) asks for using a 'scope'. There should be a way to control the
>> claims that are sent out based on the application. This is because the
>> sensitive nature of a claim depends on the application and other factors as
>> well. For example, 'phone number' might be a sensitive claim for some apps.
>> Therefore for such apps, we need to have a  way to control a client from
>> getting hold of that claim using scope 'phone'.
>>
>> So we can consider "requested claims" in Service Provider config as our
>> way of allowing an application admin to decide what claims an external
>> client can retrieve and what not.
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
>>>
>>> On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
>>> wrote:
>>>
 Hi,

 Yes. We do support openid scopes (address, email, phone, profile).
 (Refer [1])
 But as Tharindu has mentioned this too requires the relevant claims
 that fall under these scopes to be configured as requested claims in the
 Service Provider.

 For example,
 OIDC scope 'address' would return "address" and "street" claims. But
 unless you have these claims as requested claims in the claim configuration
 of the SP. These claims won't be returned although you requested the token
 with a scope value of "openid address"

 The idea here is Service Provider requested claims takes priority over
 claims defined for scopes.


 [1] https://docs.wso2.com/display/IS530/Configuring+Claims+f
 or+a+Service+Provider (Click to view vital information when
 configuring claims for an OpenID Connect Service Provider)


 Thanks,
 Farasath Ahamed
 Software Engineer, WSO2 Inc.; http://wso2.com
 Mobile: +94777603866
 Blog: blog.farazath.com
 Twitter: @farazath619 
 



 On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara <
 bhath...@wso2.com> wrote:

> @IS team: Do we support these in our current implementation?
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Hi Tharindu,
>>
>> In OIDC there are other standard scopes[1] in addition to 'openid'.
>> These scopes are there to request specific user claims. I think we can 
>> use
>> them here. So when generating tokens, these scopes should be used as per
>> the requirement.
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> We had a use case on APIM to send the user claims in the JWT Header
>>> to the backend server.
>>>
>>> Currently APIM C4 architecture was Getting the user claims and
>>> generate JWT from Key manager node.
>>>
>>> As in C5 architecture, we have to get the user claims from the IS or
>>> the third party key manager.
>>>
>>> I had observed below two ways of getting user claims into the
>>> Gateway from IS.
>>>
>>> 1. Generate token 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Ishara Karunarathna]

Hi,

In the current implementations you get a JWT token from token validation
service regardless of the grant types.
But this would be a problem when you go with standards only. For example
you may not be able to get and ID token from IDP if its only supporting
specifications.

so this has to be address case by case.
-Ishara

On Sat, May 13, 2017 at 10:40 PM, Bhathiya Jayasekara 
wrote:

> Thanks for the explanation Farasath.
>
> So this means we have to do a DCR call and another service call to
> register claims to SP. @Tharindu: looks like we don't have a choice here.
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed 
> wrote:
>
>>
>> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara 
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> That's going to be a problem when we use DCR, I guess. Shouldn't we send
>>> the claims given in the spec for each scope by default, without any special
>>> configurations in SP?
>>>
>>
>> Not really.
>>
>> Even the spec says[1],
>>
>> In some cases, the End-User will be given the option to have the OpenID
>>> Provider decline to provide some or all information requested by RPs. To
>>> minimize the amount of information that the End-User is being asked to
>>> disclose, an RP can elect to only request a subset of the information
>>> available from the UserInfo Endpoint.
>>
>>
>> Simply put we are not bound to provide all the claims a client(Relying
>> party) asks for using a 'scope'. There should be a way to control the
>> claims that are sent out based on the application. This is because the
>> sensitive nature of a claim depends on the application and other factors as
>> well. For example, 'phone number' might be a sensitive claim for some apps.
>> Therefore for such apps, we need to have a  way to control a client from
>> getting hold of that claim using scope 'phone'.
>>
>> So we can consider "requested claims" in Service Provider config as our
>> way of allowing an application admin to decide what claims an external
>> client can retrieve and what not.
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
>>>
>>> On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
>>> wrote:
>>>
 Hi,

 Yes. We do support openid scopes (address, email, phone, profile).
 (Refer [1])
 But as Tharindu has mentioned this too requires the relevant claims
 that fall under these scopes to be configured as requested claims in the
 Service Provider.

 For example,
 OIDC scope 'address' would return "address" and "street" claims. But
 unless you have these claims as requested claims in the claim configuration
 of the SP. These claims won't be returned although you requested the token
 with a scope value of "openid address"

 The idea here is Service Provider requested claims takes priority over
 claims defined for scopes.


 [1] https://docs.wso2.com/display/IS530/Configuring+Claims+f
 or+a+Service+Provider (Click to view vital information when
 configuring claims for an OpenID Connect Service Provider)


 Thanks,
 Farasath Ahamed
 Software Engineer, WSO2 Inc.; http://wso2.com
 Mobile: +94777603866
 Blog: blog.farazath.com
 Twitter: @farazath619 
 



 On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara <
 bhath...@wso2.com> wrote:

> @IS team: Do we support these in our current implementation?
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Hi Tharindu,
>>
>> In OIDC there are other standard scopes[1] in addition to 'openid'.
>> These scopes are there to request specific user claims. I think we can 
>> use
>> them here. So when generating tokens, these scopes should be used as per
>> the requirement.
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> We had a use case on APIM to send the user claims in the JWT Header
>>> to the backend server.
>>>
>>> Currently APIM C4 architecture was Getting the user claims and
>>> generate JWT from Key manager node.
>>>
>>> As in C5 architecture, we have to get the user claims from the IS or
>>> the third party key manager.
>>>
>>> I had observed below two ways of getting user claims into the
>>> Gateway from IS.
>>>
>>> 1. Generate token with OpenID scope.
>>> 2. Call userinfo endpoint with above generated token
>>> 3. Call OAuth2TokenValidation Service and get the token.
>>>
>>> When considering [2] in 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Bhathiya Jayasekara]

Thanks for the explanation Farasath.

So this means we have to do a DCR call and another service call to register
claims to SP. @Tharindu: looks like we don't have a choice here.

Thanks,
Bhathiya

On Sat, May 13, 2017 at 1:49 PM, Farasath Ahamed  wrote:

>
> On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara 
> wrote:
>
>> Hi Farasath,
>>
>> That's going to be a problem when we use DCR, I guess. Shouldn't we send
>> the claims given in the spec for each scope by default, without any special
>> configurations in SP?
>>
>
> Not really.
>
> Even the spec says[1],
>
> In some cases, the End-User will be given the option to have the OpenID
>> Provider decline to provide some or all information requested by RPs. To
>> minimize the amount of information that the End-User is being asked to
>> disclose, an RP can elect to only request a subset of the information
>> available from the UserInfo Endpoint.
>
>
> Simply put we are not bound to provide all the claims a client(Relying
> party) asks for using a 'scope'. There should be a way to control the
> claims that are sent out based on the application. This is because the
> sensitive nature of a claim depends on the application and other factors as
> well. For example, 'phone number' might be a sensitive claim for some apps.
> Therefore for such apps, we need to have a  way to control a client from
> getting hold of that claim using scope 'phone'.
>
> So we can consider "requested claims" in Service Provider config as our
> way of allowing an application admin to decide what claims an external
> client can retrieve and what not.
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>
>
>> Thanks,
>> Bhathiya
>>
>>
>>
>> On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
>> wrote:
>>
>>> Hi,
>>>
>>> Yes. We do support openid scopes (address, email, phone, profile).
>>> (Refer [1])
>>> But as Tharindu has mentioned this too requires the relevant claims that
>>> fall under these scopes to be configured as requested claims in the Service
>>> Provider.
>>>
>>> For example,
>>> OIDC scope 'address' would return "address" and "street" claims. But
>>> unless you have these claims as requested claims in the claim configuration
>>> of the SP. These claims won't be returned although you requested the token
>>> with a scope value of "openid address"
>>>
>>> The idea here is Service Provider requested claims takes priority over
>>> claims defined for scopes.
>>>
>>>
>>> [1] https://docs.wso2.com/display/IS530/Configuring+Claims+f
>>> or+a+Service+Provider (Click to view vital information when configuring
>>> claims for an OpenID Connect Service Provider)
>>>
>>>
>>> Thanks,
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>> On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara >> > wrote:
>>>
 @IS team: Do we support these in our current implementation?

 Thanks,
 Bhathiya

 On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara <
 bhath...@wso2.com> wrote:

> Hi Tharindu,
>
> In OIDC there are other standard scopes[1] in addition to 'openid'.
> These scopes are there to request specific user claims. I think we can use
> them here. So when generating tokens, these scopes should be used as per
> the requirement.
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> Hi All,
>>
>> We had a use case on APIM to send the user claims in the JWT Header
>> to the backend server.
>>
>> Currently APIM C4 architecture was Getting the user claims and
>> generate JWT from Key manager node.
>>
>> As in C5 architecture, we have to get the user claims from the IS or
>> the third party key manager.
>>
>> I had observed below two ways of getting user claims into the Gateway
>> from IS.
>>
>> 1. Generate token with OpenID scope.
>> 2. Call userinfo endpoint with above generated token
>> 3. Call OAuth2TokenValidation Service and get the token.
>>
>> When considering [2] in order to receive user info we have to set the
>> requested claims in service provider according to the App.
>>
>> And from Current C4 architecture, we don't mandate to send openid
>> token as a scope.
>>
>> Is there any other alternative ways to achieve above task.
>>
>> Thanks
>>
>> *Tharindu Dharmarathna*Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091 <077%20910%209091>*
>>
>
>
>
> --
> *Bhathiya Jayasekara*

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Farasath Ahamed]

On Sat, May 13, 2017 at 1:15 PM, Bhathiya Jayasekara 
wrote:

> Hi Farasath,
>
> That's going to be a problem when we use DCR, I guess. Shouldn't we send
> the claims given in the spec for each scope by default, without any special
> configurations in SP?
>

Not really.

Even the spec says[1],

In some cases, the End-User will be given the option to have the OpenID
> Provider decline to provide some or all information requested by RPs. To
> minimize the amount of information that the End-User is being asked to
> disclose, an RP can elect to only request a subset of the information
> available from the UserInfo Endpoint.


Simply put we are not bound to provide all the claims a client(Relying
party) asks for using a 'scope'. There should be a way to control the
claims that are sent out based on the application. This is because the
sensitive nature of a claim depends on the application and other factors as
well. For example, 'phone number' might be a sensitive claim for some apps.
Therefore for such apps, we need to have a  way to control a client from
getting hold of that claim using scope 'phone'.

So we can consider "requested claims" in Service Provider config as our way
of allowing an application admin to decide what claims an external client
can retrieve and what not.

[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims


> Thanks,
> Bhathiya
>
>
>
> On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed 
> wrote:
>
>> Hi,
>>
>> Yes. We do support openid scopes (address, email, phone, profile). (Refer
>> [1])
>> But as Tharindu has mentioned this too requires the relevant claims that
>> fall under these scopes to be configured as requested claims in the Service
>> Provider.
>>
>> For example,
>> OIDC scope 'address' would return "address" and "street" claims. But
>> unless you have these claims as requested claims in the claim configuration
>> of the SP. These claims won't be returned although you requested the token
>> with a scope value of "openid address"
>>
>> The idea here is Service Provider requested claims takes priority over
>> claims defined for scopes.
>>
>>
>> [1] https://docs.wso2.com/display/IS530/Configuring+Claims+
>> for+a+Service+Provider (Click to view vital information when configuring
>> claims for an OpenID Connect Service Provider)
>>
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>> On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara 
>> wrote:
>>
>>> @IS team: Do we support these in our current implementation?
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara >> > wrote:
>>>
 Hi Tharindu,

 In OIDC there are other standard scopes[1] in addition to 'openid'.
 These scopes are there to request specific user claims. I think we can use
 them here. So when generating tokens, these scopes should be used as per
 the requirement.

 [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

 Thanks,
 Bhathiya

 On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

> Hi All,
>
> We had a use case on APIM to send the user claims in the JWT Header to
> the backend server.
>
> Currently APIM C4 architecture was Getting the user claims and
> generate JWT from Key manager node.
>
> As in C5 architecture, we have to get the user claims from the IS or
> the third party key manager.
>
> I had observed below two ways of getting user claims into the Gateway
> from IS.
>
> 1. Generate token with OpenID scope.
> 2. Call userinfo endpoint with above generated token
> 3. Call OAuth2TokenValidation Service and get the token.
>
> When considering [2] in order to receive user info we have to set the
> requested claims in service provider according to the App.
>
> And from Current C4 architecture, we don't mandate to send openid
> token as a scope.
>
> Is there any other alternative ways to achieve above task.
>
> Thanks
>
> *Tharindu Dharmarathna*Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091 <077%20910%209091>*
>



 --
 *Bhathiya Jayasekara*
 *Associate Technical Lead,*
 *WSO2 inc., http://wso2.com *

 *Phone: +94715478185 <071%20547%208185>*
 *LinkedIn: http://www.linkedin.com/in/bhathiyaj
 *
 *Twitter: https://twitter.com/bhathiyax *
 *Blog: http://movingaheadblog.blogspot.com
 *

>>>
>>>
>>>
>>> --
>>> 

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Bhathiya Jayasekara]

Hi Farasath,

That's going to be a problem when we use DCR, I guess. Shouldn't we send
the claims given in the spec for each scope by default, without any special
configurations in SP?

Thanks,
Bhathiya



On Sat, May 13, 2017 at 1:09 PM, Farasath Ahamed  wrote:

> Hi,
>
> Yes. We do support openid scopes (address, email, phone, profile). (Refer
> [1])
> But as Tharindu has mentioned this too requires the relevant claims that
> fall under these scopes to be configured as requested claims in the Service
> Provider.
>
> For example,
> OIDC scope 'address' would return "address" and "street" claims. But
> unless you have these claims as requested claims in the claim configuration
> of the SP. These claims won't be returned although you requested the token
> with a scope value of "openid address"
>
> The idea here is Service Provider requested claims takes priority over
> claims defined for scopes.
>
>
> [1] https://docs.wso2.com/display/IS530/Configuring+
> Claims+for+a+Service+Provider (Click to view vital information when
> configuring claims for an OpenID Connect Service Provider)
>
>
> Thanks,
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
> On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara 
> wrote:
>
>> @IS team: Do we support these in our current implementation?
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara 
>> wrote:
>>
>>> Hi Tharindu,
>>>
>>> In OIDC there are other standard scopes[1] in addition to 'openid'.
>>> These scopes are there to request specific user claims. I think we can use
>>> them here. So when generating tokens, these scopes should be used as per
>>> the requirement.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 Hi All,

 We had a use case on APIM to send the user claims in the JWT Header to
 the backend server.

 Currently APIM C4 architecture was Getting the user claims and generate
 JWT from Key manager node.

 As in C5 architecture, we have to get the user claims from the IS or
 the third party key manager.

 I had observed below two ways of getting user claims into the Gateway
 from IS.

 1. Generate token with OpenID scope.
 2. Call userinfo endpoint with above generated token
 3. Call OAuth2TokenValidation Service and get the token.

 When considering [2] in order to receive user info we have to set the
 requested claims in service provider according to the App.

 And from Current C4 architecture, we don't mandate to send openid token
 as a scope.

 Is there any other alternative ways to achieve above task.

 Thanks

 *Tharindu Dharmarathna*Senior Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: *+94779109091 <077%20910%209091>*

>>>
>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Associate Technical Lead,*
>>> *WSO2 inc., http://wso2.com *
>>>
>>> *Phone: +94715478185 <071%20547%208185>*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> *
>>> *Twitter: https://twitter.com/bhathiyax *
>>> *Blog: http://movingaheadblog.blogspot.com
>>> *
>>>
>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Associate Technical Lead,*
>> *WSO2 inc., http://wso2.com *
>>
>> *Phone: +94715478185 <+94%2071%20547%208185>*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> *
>> *Twitter: https://twitter.com/bhathiyax *
>> *Blog: http://movingaheadblog.blogspot.com
>> *
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 
*Bhathiya Jayasekara*
*Associate Technical Lead,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Farasath Ahamed]

On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna 
wrote:

> Hi All,
>
> We had a use case on APIM to send the user claims in the JWT Header to the
> backend server.
>
> Currently APIM C4 architecture was Getting the user claims and generate
> JWT from Key manager node.
>
> As in C5 architecture, we have to get the user claims from the IS or the
> third party key manager.
>
> I had observed below two ways of getting user claims into the Gateway from
> IS.
>
> 1. Generate token with OpenID scope.
> 2. Call userinfo endpoint with above generated token
>
3. Call OAuth2TokenValidation Service and get the token.
>

Since these are standard ways of getting user information I would prefer
either 1 or 2.


>
> When considering [2] in order to receive user info we have to set the
> requested claims in service provider according to the App.
>
> And from Current C4 architecture, we don't mandate to send openid token as
> a scope.
>
> Is there any other alternative ways to achieve above task.
>
> Thanks
>
> *Tharindu Dharmarathna*Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091 <+94%2077%20910%209091>*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Farasath Ahamed]

Hi,

Yes. We do support openid scopes (address, email, phone, profile). (Refer
[1])
But as Tharindu has mentioned this too requires the relevant claims that
fall under these scopes to be configured as requested claims in the Service
Provider.

For example,
OIDC scope 'address' would return "address" and "street" claims. But unless
you have these claims as requested claims in the claim configuration of the
SP. These claims won't be returned although you requested the token with a
scope value of "openid address"

The idea here is Service Provider requested claims takes priority over
claims defined for scopes.


[1]
https://docs.wso2.com/display/IS530/Configuring+Claims+for+a+Service+Provider
(Click to view vital information when configuring claims for an OpenID
Connect Service Provider)


Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 




On Sat, May 13, 2017 at 11:36 AM, Bhathiya Jayasekara 
wrote:

> @IS team: Do we support these in our current implementation?
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara 
> wrote:
>
>> Hi Tharindu,
>>
>> In OIDC there are other standard scopes[1] in addition to 'openid'. These
>> scopes are there to request specific user claims. I think we can use them
>> here. So when generating tokens, these scopes should be used as per the
>> requirement.
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>
>> Thanks,
>> Bhathiya
>>
>> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> We had a use case on APIM to send the user claims in the JWT Header to
>>> the backend server.
>>>
>>> Currently APIM C4 architecture was Getting the user claims and generate
>>> JWT from Key manager node.
>>>
>>> As in C5 architecture, we have to get the user claims from the IS or the
>>> third party key manager.
>>>
>>> I had observed below two ways of getting user claims into the Gateway
>>> from IS.
>>>
>>> 1. Generate token with OpenID scope.
>>> 2. Call userinfo endpoint with above generated token
>>> 3. Call OAuth2TokenValidation Service and get the token.
>>>
>>> When considering [2] in order to receive user info we have to set the
>>> requested claims in service provider according to the App.
>>>
>>> And from Current C4 architecture, we don't mandate to send openid token
>>> as a scope.
>>>
>>> Is there any other alternative ways to achieve above task.
>>>
>>> Thanks
>>>
>>> *Tharindu Dharmarathna*Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94779109091 <077%20910%209091>*
>>>
>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Associate Technical Lead,*
>> *WSO2 inc., http://wso2.com *
>>
>> *Phone: +94715478185 <071%20547%208185>*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> *
>> *Twitter: https://twitter.com/bhathiyax *
>> *Blog: http://movingaheadblog.blogspot.com
>> *
>>
>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Bhathiya Jayasekara]

@IS team: Do we support these in our current implementation?

Thanks,
Bhathiya

On Sat, May 13, 2017 at 11:34 AM, Bhathiya Jayasekara 
wrote:

> Hi Tharindu,
>
> In OIDC there are other standard scopes[1] in addition to 'openid'. These
> scopes are there to request specific user claims. I think we can use them
> here. So when generating tokens, these scopes should be used as per the
> requirement.
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>
> Thanks,
> Bhathiya
>
> On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> Hi All,
>>
>> We had a use case on APIM to send the user claims in the JWT Header to
>> the backend server.
>>
>> Currently APIM C4 architecture was Getting the user claims and generate
>> JWT from Key manager node.
>>
>> As in C5 architecture, we have to get the user claims from the IS or the
>> third party key manager.
>>
>> I had observed below two ways of getting user claims into the Gateway
>> from IS.
>>
>> 1. Generate token with OpenID scope.
>> 2. Call userinfo endpoint with above generated token
>> 3. Call OAuth2TokenValidation Service and get the token.
>>
>> When considering [2] in order to receive user info we have to set the
>> requested claims in service provider according to the App.
>>
>> And from Current C4 architecture, we don't mandate to send openid token
>> as a scope.
>>
>> Is there any other alternative ways to achieve above task.
>>
>> Thanks
>>
>> *Tharindu Dharmarathna*Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091 <077%20910%209091>*
>>
>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>



-- 
*Bhathiya Jayasekara*
*Associate Technical Lead,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][C5] - Best Way to get the end user information

[Bhathiya Jayasekara]

Hi Tharindu,

In OIDC there are other standard scopes[1] in addition to 'openid'. These
scopes are there to request specific user claims. I think we can use them
here. So when generating tokens, these scopes should be used as per the
requirement.

[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

Thanks,
Bhathiya

On Sat, May 13, 2017 at 12:18 AM, Tharindu Dharmarathna 
wrote:

> Hi All,
>
> We had a use case on APIM to send the user claims in the JWT Header to the
> backend server.
>
> Currently APIM C4 architecture was Getting the user claims and generate
> JWT from Key manager node.
>
> As in C5 architecture, we have to get the user claims from the IS or the
> third party key manager.
>
> I had observed below two ways of getting user claims into the Gateway from
> IS.
>
> 1. Generate token with OpenID scope.
> 2. Call userinfo endpoint with above generated token
> 3. Call OAuth2TokenValidation Service and get the token.
>
> When considering [2] in order to receive user info we have to set the
> requested claims in service provider according to the App.
>
> And from Current C4 architecture, we don't mandate to send openid token as
> a scope.
>
> Is there any other alternative ways to achieve above task.
>
> Thanks
>
> *Tharindu Dharmarathna*Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091 <077%20910%209091>*
>



-- 
*Bhathiya Jayasekara*
*Associate Technical Lead,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev