For federated users, it's ok to prompt missing attributes every time (unless they are associated and assert with a local user). I think we should display a message like [1].
What happens when we try federated login that associated with local user and also assert with local user? Does that work without changing current implementation? And giving the option to associate user during the JIT provioning is an addional capability which also requested by many. We would need to done as a improvement for JIT provioning. For the perspective of this feature, if it works with manually associated (and locally asserted users), it would also work automatically associated users. [1] "You are trying login to application x, but it need following information filled in the user profile. You can fill those below and proceed with the authentication. But it's adviced to fill this information in your y-IdP profile in order to avoid this step every time you login." Thanks, On Wednesday, 26 October 2016, Nuwandi Wickramasinghe <[email protected]> wrote: > Hi, > > This feature includes saving the attributes provided at authentication > time to the user profile so the mandatory attributes will be present in the > user profile from the next time user tries to access the application. At > the moment, attributes are saved only for the local users. > > If the user is coming from a federated identity provider and the federated > idp does not send any of the mandatory attributes, user will be prompted to > provide them during the authentication. These provided attributes will be > sent to the application but not saved. Therefore if the user tries to > access the application again, he might have to provide the same attributes > (if idp is not sending them). > > If JIT provisioning is enabled for this identity provider, this federated > user will be provisioned to a local user store where we can update and save > provided attributes. But when this federated user tries to access the > application again, unless the federated user has an association with a > local account, handlePostAuthentication() method does not read attributes > from a local account, resulting in user having to provide attributes again. > > So if we need to avoid prompting for same attributes from the same user > (provisioned user) again and again we can do following, > > 1. For the JIT provisioned users, check the local profile for missing > attributes before requesting them from user. > 2. Automatically associate federated user with the provisioned user at the > time of provisioning. > > Any comments about the current issue and above two suggestions and/or new > suggestions are highly appreciated. > > thanks and best regards > Nuwandi > > On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Hi all, >> >> This new feature, provided with IS 5.3.0, allows to define mandatory >> attributes for an application during the Service Provider configuration >> time. When a user tries to access the application, during authentication, >> IS will check whether the user has mandatory attributes requested by the >> application. If any mandatory attribute is missing, IS will prompt a page >> where user can provide mandatory claims for that application. >> >> Current implementation is to check the missing mandatory claims at the >> authentication framework as a post authentication task. >> *DefaultStepBasedSequenceHandler* handles the authentication from the >> steps configured for the application. Once all the steps are successfully >> completed, *handlePostAuthentication() *method is fired. This method >> gets the user attributes from attribute step and adds them to >> *AuthenticatedUser* object which will be used to send user details to >> the application. Handling of missing mandatory attributes, is implemented >> as a post authentication extension. Post authentication extension is called >> at the end of *handlePostAuthentication().* >> >> After post authentication is done, following additional steps are >> implemented for the feature. >> >> 1. Post authentication extension compares mandatory attributes defined in >> Service Provider configuration with the user attributes found in >> AuthenticatedUser object. ( If no attributes are missing, it proceeds with >> Authentication Complete state) >> >> (If one or more attributes are missing) >> 2. Authentication and sequence is set to "Incomplete" state. A property >> is set in Authentication Context to identify that post authentication >> extension triggered an action. >> >> 3. User is redirected to a page which requests missing attributes. >> >> 4. Once user submits values in the page, a post request is made to the >> authentication framework (commonauth servlet) with attribute values and >> context identifier (sent from the framework). >> >> 5. Authentication framework identifies the authenticated context from the >> context identifier. Framework will skip authentication steps since it's >> already authenticated and set the sequence state to "completed" and then >> call *handlePostAuthentication().* >> >> 6. In *handlePostAuthentication()*, it checks the property set in step 2 >> and identifies this as the response of post authentication extension task >> therefore calls the post authentication extension. >> >> 7. Response handler in post authentication extension, reads the >> attributes from request, sets them as user attributes in AuthenticatedUser >> object and completes the authentication. So application will receive all >> the mandatory attributes for that. >> >> this is the current implementation of this feature. >> >> thank you >> Nuwandi >> >> -- >> >> Best Regards, >> >> Nuwandi Wickramasinghe >> >> Software Engineer >> >> WSO2 Inc. >> >> Web : http://wso2.com >> >> Mobile : 0719214873 >> > > > > -- > > Best Regards, > > Nuwandi Wickramasinghe > > Software Engineer > > WSO2 Inc. > > Web : http://wso2.com > > Mobile : 0719214873 > -- Regards, *Darshana Gunawardana*Associate Technical Lead WSO2 Inc.; http://wso2.com *E-mail: [email protected] <[email protected]>* *Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
