Hi Hasanthi, On Thu, Jan 25, 2018 at 11:30 AM, Johann Nallathamby <[email protected]> wrote:
> Hi Hasanthi, > > On Wed, Jan 24, 2018 at 11:14 PM, Hasanthi Purnima Dissanayake < > [email protected]> wrote: > >> Hi Johann, >> >> First of all apologies for the late reply :). >> >> Hi Hasanthi, >>> >>> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake < >>> [email protected]> wrote: >>> >>>> Hi Johann, >>>> >>>> Is there any instance in which IS will throw error to client because it >>>>> cannot send the claim? >>>>> >>>>> Because in the spec it says the following. >>>>> >>>>> Note that even if the Claims are not available because the End-User >>>>> did not authorize their release or they are not present, the Authorization >>>>> Server MUST NOT generate an error when Claims are not returned, whether >>>>> they are Essential or Voluntary, unless otherwise specified in the >>>>> description of the specific claim. >>>>> >>>>> So IMO we need to have a property for each claim that says whether we >>>>> return an error or not. >>>>> >>>>> Wdyt? >>>>> >>>> >>>> What I understand from the above is, if a claim is marked as essential >>>> or voluntary and if the server can not return the claim the flow should not >>>> break and server should not throw an error if it is not specially specified >>>> in the server side. In this scope we don't specify this from server side. >>>> Though this is not a MUST we can add this as an improvement as it adds a >>>> value. >>>> >>> >>> So IIUC in any circumstance we don't send an error to client. Correct? >>> >>> Yes, we can add that property as an improvement. >>> >>>> >>>> >>>>>> 2. The claims like "nickname" it will act as a default claim and will >>>>>> control by both requested scopes and the requested claims. >>>>>> >>>>> >>>>> What do you mean by controlling using requested scope? Do you mean if >>>>> the client doesn't request at least one scope that includes this claim we >>>>> won't return that claim? I don't think that is mentioned in the spec. Can >>>>> you clarify? >>>>> >>>> >>>> The spec does not directly specify how should we treat for the Voluntary >>>> Claim from the server side. So what we have planned to do is to honour the >>>> scopes and server level requested claims when returning this claim. >>>> >>> >>> IMO, because the spec doesn't say to do anything special on the OP side >>> about not being able to release a particular claim (it says not to break >>> the normal flow), there is nothing special we can differentiate between >>> essential and voluntary claims. Only thing we may be able to do is, give a >>> warning to user saying that if s/he doesn't approve an essential claim s/he >>> won't be able to work with the application smoothly. We can't do anything >>> beyond that right? >>> >>> When you say scopes which scopes are you referring to? Are they the >>> requested scopes in the request or the defined scopes in the registry? I >>> fail to understand what scopes have to do with claims in this case. >>> Following is what I find in spec related to this. >>> >> >> Here what I meant was requested scopes in the request. In this case the >> request object itself can contain scope values. If there are scopes in the >> request object , the authorization request scopes will be overriden from >> those scopes. >> > > That is fine, if that's what the spec says. My concern is not about that. > My concern is if there is a requested claim in the request object we must > return it. We don't need check them against scopes. > You might have missed to confirm on this. This is the most important point. Do you also agree that any requested claim in the request object must be returned regardless of the scopes we have requested or registered? Regards, Johann. >> >>> "It is also the only way to request specific combinations of the >>> standard Claims that cannot be specified using scope values. " >>> >>> As I understand if the specific requested OIDC claim, is defined in the >>> OIDC dialect, the user has a value for that claim and s/he has approved >>> that claim for the RP, then we can send them to the RP, regardless of >>> whether it is defined in scope or not. Otherwise we are contradicting the >>> above statement right? >>> >> >> BTW, the above statement is for 'claim' parameter not for 'request' >> parameter right? >> > > Yes it is about claim parameter. > > >> If it is related to 'request' parameter as well then I also feel it is >> wrong to depend on the scopes here. So if we skip checking the requested >> scope for both voluntary and essential claims, how will be the server >> response for essential :true (essential), essential:false and null >> (voluntary) values? >> > > This is what I said. The server response for any kind of claim parameter > (essential or voluntary) is the same. Any reason to disagree? > > Regards, > Johann. > > >> >> Thanks, >> >> >> >> >> On Wed, Jan 24, 2018 at 9:14 PM, Johann Nallathamby <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Jan 24, 2018 at 2:12 PM, Farasath Ahamed <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tuesday, January 23, 2018, Johann Nallathamby <[email protected]> >>>> wrote: >>>> >>>>> Hi Farasath, >>>>> >>>>> On Tue, Jan 23, 2018 at 12:13 PM, Farasath Ahamed <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tuesday, January 23, 2018, Johann Nallathamby <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Hasanthi, >>>>>>> >>>>>>> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Johann, >>>>>>>> >>>>>>>> Is there any instance in which IS will throw error to client >>>>>>>>> because it cannot send the claim? >>>>>>>>> >>>>>>>>> Because in the spec it says the following. >>>>>>>>> >>>>>>>>> Note that even if the Claims are not available because the >>>>>>>>> End-User did not authorize their release or they are not present, the >>>>>>>>> Authorization Server MUST NOT generate an error when Claims are not >>>>>>>>> returned, whether they are Essential or Voluntary, unless otherwise >>>>>>>>> specified in the description of the specific claim. >>>>>>>>> >>>>>>>>> So IMO we need to have a property for each claim that says whether >>>>>>>>> we return an error or not. >>>>>>>>> >>>>>>>>> Wdyt? >>>>>>>>> >>>>>>>> >>>>>>>> What I understand from the above is, if a claim is marked as >>>>>>>> essential or voluntary and if the server can not return the claim the >>>>>>>> flow >>>>>>>> should not break and server should not throw an error if it is not >>>>>>>> specially specified in the server side. In this scope we don't specify >>>>>>>> this >>>>>>>> from server side. Though this is not a MUST we can add this as an >>>>>>>> improvement as it adds a value. >>>>>>>> >>>>>>> >>>>>>> So IIUC in any circumstance we don't send an error to client. >>>>>>> Correct? >>>>>>> >>>>>>> Yes, we can add that property as an improvement. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> 2. The claims like "nickname" it will act as a default claim and >>>>>>>>>> will control by both requested scopes and the requested claims. >>>>>>>>>> >>>>>>>>> >>>>>>>>> What do you mean by controlling using requested scope? Do you mean >>>>>>>>> if the client doesn't request at least one scope that includes this >>>>>>>>> claim >>>>>>>>> we won't return that claim? I don't think that is mentioned in the >>>>>>>>> spec. >>>>>>>>> Can you clarify? >>>>>>>>> >>>>>>>> >>>>>>>> The spec does not directly specify how should we treat for the >>>>>>>> Voluntary >>>>>>>> Claim from the server side. So what we have planned to do is to honour >>>>>>>> the >>>>>>>> scopes and server level requested claims when returning this claim. >>>>>>>> >>>>>>> >>>>>>> IMO, because the spec doesn't say to do anything special on the OP >>>>>>> side about not being able to release a particular claim (it says not to >>>>>>> break the normal flow), there is nothing special we can differentiate >>>>>>> between essential and voluntary claims. Only thing we may be able to do >>>>>>> is, >>>>>>> give a warning to user saying that if s/he doesn't approve an essential >>>>>>> claim s/he won't be able to work with the application smoothly. We >>>>>>> can't do >>>>>>> anything beyond that right? >>>>>>> >>>>>>> When you say scopes which scopes are you referring to? Are they the >>>>>>> requested scopes in the request or the defined scopes in the registry? I >>>>>>> fail to understand what scopes have to do with claims in this case. >>>>>>> Following is what I find in spec related to this. >>>>>>> >>>>>>> "It is also the only way to request specific combinations of the >>>>>>> standard Claims that cannot be specified using scope values. " >>>>>>> >>>>>>> As I understand if the specific requested OIDC claim, is defined in >>>>>>> the OIDC dialect, the user has a value for that claim and s/he has >>>>>>> approved >>>>>>> that claim for the RP, then we can send them to the RP, regardless of >>>>>>> whether it is defined in scope or not. Otherwise we are contradicting >>>>>>> the >>>>>>> above statement right? >>>>>>> >>>>>>> Also regarding requested claims in service provider configuration, >>>>>>> IIRC we used it as a way to control access to certain claims by service >>>>>>> providers, which overrides the requested scopes and requested claims. >>>>>>> *But >>>>>>> that is only if the requested claims list is not empty in service >>>>>>> provider >>>>>>> configuration*. I.e. requested claims in service provider >>>>>>> configuration must have at least 1 claim. Otherwise what will happen is >>>>>>> for >>>>>>> every service provider we need to add all the OIDC claims if they are >>>>>>> going >>>>>>> to request claims dynamically, using scopes or requested claims in the >>>>>>> request. Do I make sense or am I missing something? >>>>>>> >>>>>> >>>>>> In our current implementation requested claims and claims included in >>>>>> requested scopes act as two filters for user claims sent to service >>>>>> provider. >>>>>> >>>>>> First user claims are filtered by requested claims and then by claims >>>>>> included in requested scope. So if an SP doesn't have any claims >>>>>> configured >>>>>> as requested claims then no claims will be sent our in id_token or >>>>>> userinfo >>>>>> response. >>>>>> >>>>>> From IS 5.2.0 this has been the behaviour. >>>>>> >>>>> >>>>> Thanks for the info. This is not violating anything. But I feel it's a >>>>> huge pain to configure all the claims as requested claims for all the >>>>> service providers. I think we have around 25 OIDC claims. And if we have >>>>> around 10 service providers that means we need to configure 250 claims. >>>>> >>>>> I believe we need to improve this. I think for OIDC implementation we >>>>> can interpret requested claims the way I have mentioned above. I.e. if the >>>>> list is empty we don't have to restrict anything. We can send all the >>>>> claims defined under "oidc" scope + requested scopes in request + >>>>> requested >>>>> claims in request. If at least one requested claim is defined in SP UI, >>>>> then we send the intersection of the two. >>>>> >>>>> For SAML however it will have to be interpreted differently, because >>>>> SAML2 doesn't have a way to request specific attributes. So empty list >>>>> would mean don't send any attributes. >>>>> >>>>> Wdyt? >>>>> >>>> >>>> Yes. A totally valid point about the pain the user has to go through to >>>> configure request claims at Service Provider. It gets even more frustrating >>>> for the user since he has to find the corresponding claim URI in local >>>> dialect for each OIDC claim he wants to send out the RP. >>>> >>> >>>> However, handling/interpreting claim handling specific to a protocol at >>>> Identity Framework level doesn't sound right to me. >>>> >>> >>> Wait, I have a question after reading your reply :). How do we currently >>> handle claims for OIDC specifically in authentication framework? Haven't we >>> written any code specific to OIDC by checking the request type? >>> >>> >>>> How about providing an option at Service Provider level to get all user >>>> claims from Framework? >>>> >>> >>> If we are fine to do UI changes, following will be the best approach I >>> would suggest. >>> >>> 1. In the SP UI, under Claim Configurations, we will have following >>> options (we may decide to remove something if it doesn't suit). >>> a. Send requested claims only >>> b. Send following claims only >>> c. Send requested claims + following claims >>> d. Don't send any claims >>> >>> 2. Based on the above configuration the inbound authenticator will have >>> a way to process the request and find out the claims that need to be sent >>> to the service provider. >>> >>> 3. The inbound authenticator will delegate the authentication request to >>> framework in a protocol neutral manner by specifying the requested claims. >>> >>> 4. Authentication framework retrieves the requested claims and sends it >>> along with the response to inbound authenticator, and inbound authenticator >>> will add them to final response and send it to client. >>> >>> Regards, >>> Johann. >>> >>> >>>> >>>> In a way, this is something you have proposed. The difference is rather >>>> than interpreting the "no requested claims" for OIDC. We will have a >>>> dedicated option to send all claims that can be used for any protocol. We >>>> retrieve all non-null user claims and add them to the context with our >>>> default claim handler implementation. Therefore we won't have any >>>> additional overhead to retrieve all claims. >>>> >>>> Then a user who wants to configure OIDC claims can simply select this >>>> option and then OIDC scopes to limit claims sent out the RP. >>>> WDYT? >>>> >>>> >>>> Thanks, >>>> Farasath >>>> >>>> >>>>> >>>>> Regards, >>>>> Johann. >>>>> >>>>> >>>>>>> Regards, >>>>>>> Johann. >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jan 23, 2018 at 9:05 AM, Johann Nallathamby < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Hasanthi, >>>>>>>>> >>>>>>>>> On Wed, Oct 11, 2017 at 4:35 PM, Hasanthi Purnima Dissanayake < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> In order to support 'Request Object' we need to support two >>>>>>>>>> parameters. >>>>>>>>>> 1. request parameter >>>>>>>>>> 2. request_uri parameter >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *1. request_parameter* >>>>>>>>>> The purpose of this parameter is for supporting to request some >>>>>>>>>> claims other than the default Userinfo and IdToken claim set which is >>>>>>>>>> associated with the requested scope. >>>>>>>>>> >>>>>>>>>> So if we consider a sample request with above parameter, >>>>>>>>>> >>>>>>>>>> https://localhost:9443/oauth2/authorize? >>>>>>>>>> response_type=code%20id_token >>>>>>>>>> &client_id=XXXXX >>>>>>>>>> &redirect_uri=http://localhost:8080/playground >>>>>>>>>> &scope=openid >>>>>>>>>> &state=af0ifjsldkj >>>>>>>>>> &nonce=n-0S6_WzA2Mj >>>>>>>>>> &request={ >>>>>>>>>> "iss": "s6BhdRkqt3", >>>>>>>>>> "aud": "https://server.example.com";, >>>>>>>>>> "response_type": "code id_token", >>>>>>>>>> "client_id": "s6BhdRkqt3", >>>>>>>>>> "redirect_uri": "https://client.example.org/cb";, >>>>>>>>>> "scope": "openid", >>>>>>>>>> "state": "af0ifjsldkj", >>>>>>>>>> "nonce": "n-0S6_WzA2Mj", >>>>>>>>>> "max_age": 86400, >>>>>>>>>> >>>>>>>>>> "claims": { >>>>>>>>>> "userinfo": { >>>>>>>>>> "given_name": { >>>>>>>>>> "essential": true >>>>>>>>>> }, >>>>>>>>>> "nickname": null, >>>>>>>>>> "email": { >>>>>>>>>> "essential": true >>>>>>>>>> }, >>>>>>>>>> >>>>>>>>>> "id_token": { >>>>>>>>>> "gender": null, >>>>>>>>>> "birthdate": { >>>>>>>>>> "essential": true >>>>>>>>>> }, >>>>>>>>>> "acr": { >>>>>>>>>> "values": [ >>>>>>>>>> "urn:mace:incommon:iap:silver" >>>>>>>>>> ] >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The expected behavior of Identity server will be as follows. >>>>>>>>>> >>>>>>>>>> 1.Consider the claims "given_name" and "email" which are marked >>>>>>>>>> as 'essential:true' for 'userinfo' member. Even if they are not >>>>>>>>>> mapped with >>>>>>>>>> the openid scope in the registry, if these claims are requested >>>>>>>>>> claims, >>>>>>>>>> then 'given_name' and 'email' will be returned from the Userinfo >>>>>>>>>> endpoint. >>>>>>>>>> So as a summary the claims which have marked as 'essential : true' >>>>>>>>>> only get >>>>>>>>>> controlled by the requested claims and ignore the requested scopes. >>>>>>>>>> If the >>>>>>>>>> server can not provide those essential claims there wont be any >>>>>>>>>> failure or >>>>>>>>>> error message returning from the server. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Is there any instance in which IS will throw error to client >>>>>>>>> because it cannot send the claim? >>>>>>>>> >>>>>>>>> Because in the spec it says the following. >>>>>>>>> >>>>>>>>> Note that even if the Claims are not available because the >>>>>>>>> End-User did not authorize their release or they are not present, the >>>>>>>>> Authorization Server MUST NOT generate an error when Claims are not >>>>>>>>> returned, whether they are Essential or Voluntary, unless otherwise >>>>>>>>> specified in the description of the specific claim. >>>>>>>>> >>>>>>>>> So IMO we need to have a property for each claim that says whether >>>>>>>>> we return an error or not. >>>>>>>>> >>>>>>>>> Wdyt? >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2. The claims like "nickname" it will act as a default claim and >>>>>>>>>> will control by both requested scopes and the requested claims. >>>>>>>>>> >>>>>>>>> >>>>>>>>> What do you mean by controlling using requested scope? Do you mean >>>>>>>>> if the client doesn't request at least one scope that includes this >>>>>>>>> claim >>>>>>>>> we won't return that claim? I don't think that is mentioned in the >>>>>>>>> spec. >>>>>>>>> Can you clarify? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Johann. >>>>>>>>> >>>>>>>>> >>>>>>>>>> This behavior is common to the id token as well. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *2. request_uri parameter* >>>>>>>>>> In this case the url will be a pre-registered url by the RP for >>>>>>>>>> use at the OP. The reference which is pointed from the url will >>>>>>>>>> consist the >>>>>>>>>> relevant jwt. The rationale behind returning claims will be same as >>>>>>>>>> the >>>>>>>>>> above in the request parameter. >>>>>>>>>> >>>>>>>>>> As we are planning to provide the implementation as a 5.3.0 WUM >>>>>>>>>> update the 'acr' implementation will be not available there. So if >>>>>>>>>> 'acr' >>>>>>>>>> value is requested as an essential claim a pre-define value will be >>>>>>>>>> returned. >>>>>>>>>> >>>>>>>>>> Any suggestion or feedback on the above will be highly >>>>>>>>>> appreciated. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Hasanthi Dissanayake >>>>>>>>>> >>>>>>>>>> Software Engineer | WSO2 >>>>>>>>>> >>>>>>>>>> E: [email protected] >>>>>>>>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Johann Dilantha Nallathamby* >>>>>>>>> Senior Lead Solutions Engineer >>>>>>>>> WSO2, Inc. >>>>>>>>> lean.enterprise.middleware >>>>>>>>> >>>>>>>>> Mobile: *+94 77 7776950* >>>>>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>>>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>>>>>> Medium: *https://medium.com/@johann_nallathamby >>>>>>>>> <https://medium.com/@johann_nallathamby>* >>>>>>>>> Twitter: *@dj_nallaa* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Hasanthi Dissanayake >>>>>>>> >>>>>>>> Senior Software Engineer | WSO2 >>>>>>>> >>>>>>>> E: [email protected] >>>>>>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Johann Dilantha Nallathamby* >>>>>>> Senior Lead Solutions Engineer >>>>>>> WSO2, Inc. >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> Mobile: *+94 77 7776950* >>>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>>>> Medium: *https://medium.com/@johann_nallathamby >>>>>>> <https://medium.com/@johann_nallathamby>* >>>>>>> Twitter: *@dj_nallaa* >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Farasath Ahamed >>>>>> Senior Software Engineer, WSO2 Inc.; http://wso2.com >>>>>> Mobile: +94777603866 >>>>>> Blog: blog.farazath.com >>>>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>>>> <http://wso2.com/signature> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Johann Dilantha Nallathamby* >>>>> Senior Lead Solutions Engineer >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile: *+94 77 7776950* >>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>> Medium: *https://medium.com/@johann_nallathamby >>>>> <https://medium.com/@johann_nallathamby>* >>>>> Twitter: *@dj_nallaa* >>>>> >>>> >>> >>> >>> -- >>> >>> *Johann Dilantha Nallathamby* >>> Senior Lead Solutions Engineer >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile: *+94 77 7776950* >>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>> <http://www.linkedin.com/in/johann-nallathamby>* >>> Medium: *https://medium.com/@johann_nallathamby >>> <https://medium.com/@johann_nallathamby>* >>> Twitter: *@dj_nallaa* >>> >> >> >> >> -- >> >> Hasanthi Dissanayake >> >> Senior Software Engineer | WSO2 >> >> E: [email protected] >> M :0718407133| http://wso2.com <http://wso2.com/> >> > > > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile: *+94 77 7776950* > LinkedIn: *http://www.linkedin.com/in/johann-nallathamby > <http://www.linkedin.com/in/johann-nallathamby>* > Medium: *https://medium.com/@johann_nallathamby > <https://medium.com/@johann_nallathamby>* > Twitter: *@dj_nallaa* > -- *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile: *+94 77 7776950* LinkedIn: *http://www.linkedin.com/in/johann-nallathamby <http://www.linkedin.com/in/johann-nallathamby>* Medium: *https://medium.com/@johann_nallathamby <https://medium.com/@johann_nallathamby>* Twitter: *@dj_nallaa*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
