Hi Johann, 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? >
+1. This make sense. Lets consider the same server response for any claim parameter value. Thanks Johann. Thanks, 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. > >> >> >>> "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* > -- Hasanthi Dissanayake Senior Software Engineer | WSO2 E: [email protected] M :0718407133| http://wso2.com <http://wso2.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
