Hi, On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[email protected]> wrote:
> 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]. +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. > I think in the above case if we have anable jit for that federated authenticator lets set the option to store those attributes. -Ishara > > [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]> 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 <%2B94718566859>*Lean . Enterprise . Middleware > > -- Ishara Karunarathna Associate Technical Lead WSO2 Inc. - lean . enterprise . middleware | wso2.com email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
