Hi, On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[email protected]> wrote:
> > > 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]. > > > I don't know if the message in [1] will always be suitable, but since we > can customize this message it should be fine. Because it really depends on > the configurations admin has made in the IDP side also. So if > configurations are correct then user can fill his profile in the federated > IDP side and avoid filling attributes in IS. > > >> >> 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. >> > > So are we going to automatically associate JIT provisioned users? > Otherwise each time it will request for attributes from user as I > understand. > > >> >> [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. >>> >> > My preference is option 2 because it solves some other use cases we can't > do now. > +1 for this option. > > >> >>> 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 >> >> > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Technical Lead & Product Lead of WSO2 Identity Server > Governance Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- 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
