After , the use get authenticated and try to login to same sp by using different tab also we may have to prompt the input screen because there may be additional claims will be added around this. So in that case even though the sequence config is completed, do we call the *handlePostAuthentication* *() *method implementation ? Because is saw there is if condition to check that competed or not within *handlePostAuthentication**() *method ?
On Nov 2, 2016 12:07 AM, "Johann Nallathamby" <[email protected]> wrote: > > > On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[email protected]> wrote: > >> >> >> On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[email protected]> >> wrote: >> >>> 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. >>> >> When providing missing attributes can we set password also then just in >> time provisioned user can perform local authentication as well whenever >> necessary. >> > > +1 then it becomes a possible migration strategy as well. > > >> >>>> >>>>> >>>>>> 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 >>> >>> >> >> >> -- >> Gayan Gunawardana >> Software Engineer; WSO2 Inc.; http://wso2.com/ >> Email: [email protected] >> Mobile: +94 (71) 8020933 >> > > > > -- > 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>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
