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
