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.

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 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 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 <https://twitter.com/farazath619>
>>>>>> <http://wso2.com/signature>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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#ScopeCl
>>>>>>>> aims
>>>>>>>>
>>>>>>>> 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 <http://wso2.com>*
>>>>>>>>
>>>>>>>> *Phone: +94715478185 <071%20547%208185>*
>>>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>>>>> <https://twitter.com/bhathiyax>*
>>>>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Bhathiya Jayasekara*
>>>>>>> *Associate Technical Lead,*
>>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>>>
>>>>>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>>>> <https://twitter.com/bhathiyax>*
>>>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>>>> <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 <http://wso2.com>*
>>>>>
>>>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>> <https://twitter.com/bhathiyax>*
>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Associate Technical Lead,*
>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>
>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> <http://www.linkedin.com/in/bhathiyaj>*
>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
>>> *Blog: http://movingaheadblog.blogspot.com
>>> <http://movingaheadblog.blogspot.com/>*
>>>
>>
>>
>>
>> --
>> Ishara Karunarathna
>> Associate Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791 <071%20799%206791>
>>
>>
>>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com <http://wso2.com>*
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> <http://www.linkedin.com/in/bhathiyaj>*
> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
> *Blog: http://movingaheadblog.blogspot.com
> <http://movingaheadblog.blogspot.com/>*
>



-- 
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to