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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
