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. > >> >>> >>>> 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
