Hi Indunil, On Mon, Mar 26, 2018 at 10:20 AM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote:
> Hi, > > Please find the following information on current implementation of consent > management in IS 5.5.0. > > - Claims to populate in the consent page, will be retrieved from the > claim mapping configuration in SP (i.e. claims which is configured as > requested). > - If the claims configured in SP are mentioned as mandatory (i.e. > without those claims application cannot work), consent MUST be given by > user, to proceed. > - When user have provided the consent first time, consent receipt will > be generated for that application and for that user. Then after consent > page will be shown, if there are any more mandatory claims which user has > not provided the consent to share with the application. > - If there are no SP configurations, consider that as a federated > scenario and populate all the authenticated user attributes as mandatory > claims in the consent. > > > Following is the suggested approach for handling consent management when > the requested claims are send dynamically from the authentication request. > > - *Requested/Mandatory claims are only configured in SP* > > > - Populate all the claims configured in SP, in the consent page. > > > - *Requested/Mandatory claims are not configured in SP and requested > in authentication request* > > > - From framework, set all the requested attributes to the > authenticated user (i.e. values as null for the attributes which are not > available for the user) and set the required property of the claims to > true/false. > > > - In the consent service, validate the required property and populate > the consent page. Since mandatory is a property which we have > introduced in > IS, that won't be affected for the requested claims in authentication > request. > > > - All the requested claims in authentication request will be populated > in the consent page whether user have a attribute value or not. > > > - We assume that all the user attributes for which the user consent is > needed, will be send in the first authentication request. For later > requests, consent page will not be shown. This is because, consent page > will be populated only for mandatory claims, if a consent receipt is > available for the user. > > > - Filter out and remove the null user attribute values from framework > and send to the inbound component or can be handled null values in > inbound > component. > > > - Federated claims will also be treated same way as above. > > > - *Requested/Mandatory claims are configured in SP and requested in > authentication request* > > > - Populate all the claims configured in SP, in the consent page. > > > - Here we will be not considering about the requested claims in the > request when showing the consent page. > > > So looks like you have given precedence to the attributes configured in application scope than attributes coming in request scope. With this model seems the capability to request attributes dynamically is being somewhat restricted. Because, in above when attributes are configured in application scope, attributes requested in request scope are totally ignored. I think below is how we should give precedence, but that does not mean we should not ignore latter. 1. If mandatory attributes in application scope are available get consent for mandatory attributes 2. If requested attributes in application scope are available get consent for them 3. If requested attributes in request scope are available get consent for them That means, if there are attributes in request scope which are not configured in application scope, we should get consent for them as well rather than ignoring them. Moreover, as Isura mentioned, when in a latter request a new attribute is requested in request scope, I think consent for that claim should pop up as well. Also, please have a look at how requesting claims with OIDC request object works. Both should be consistent. > Appreciate your suggestions and comments on this. > > Thanks and Regards > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email indu...@wso2.com > Mobile 0772182255 > Thanks, Malithi. -- *Malithi Edirisinghe* Associate Technical Lead WSO2 Inc. Mobile : +94 (0) 718176807 malit...@wso2.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
