On Wed, Mar 28, 2018 at 11:15 PM, Malithi Edirisinghe <malit...@wso2.com> wrote:
> 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 > -- *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
