Hi Nuwandi Can WSO2IS popup for user claims which must be provision in to the local user store (JIT provisioning) ?
If federated claims are not enough to update the user store, then it is assume that WSO2IS can popup for addition claims & persisted.. Does it work with WSO2IS 5.3.0 ? Thanks, Asela. On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe <nuwan...@wso2.com> wrote: > Sorry for the late reply. Please find the inline comments. > > thanks and regards. > > On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker < > jochen.traunec...@googlemail.com> wrote: > >> Hi, >> >> Is the user considered as successfully authenticated even if he will >> never provide the asked claims? What will be send back to SP if user is NOT >> providing any claims? >> > No. User will not be authenticated and he will not be able access service > provider. But the user will be asked to provide the claims only if they are > marked as "Mandatory" in the SP configuration in Identity Server. You can > add requested claims in SP configuration without marking them as mandatory. > In that case IS will authenticate user and send those requested claims to > the SP if they are available in user profile. > > There is the scenario with WebSSO and SP1 asking for claims SP2 is not >> interested in. While establishing the very first authentication session for >> user X with SP1, that user X might be successfully authenticated but will >> not share additional claims. Assuming some DENY response will be send back >> to SP1 and user moves forward to SP2, will he then be considered as already >> successfully authenticated ? >> > As per the current implementation, if SP1 configuration has any mandatory > claims, user will not be authenticated until he provides them. User will > have to login in to SP2 > >> >> Besides the "provide more claims" step we can expect a "confirm to share >> claims with SP-X" become a requirement, too. This could get handled in the >> handlePostAuthentication() method, too, but then expectation is that >> although a DENY is send to SP-1 (when user doesn't want to share >> information) the user is considered successfully authenticated in IdP (IS) >> with e.g. SP-2 he already confirmed before .... >> > We do not have this implemented. Basically, if SP configuration has marked > any claim as mandatory, we consider that service provider cannot be used > without that attribute. Therefore user needs to share that value with that > particular SP > >> >> Thanks, >> Jochen >> >> Harsha Thirimanna <hars...@wso2.com> schrieb am Mi. 2. Nov. 2016 um >> 06:19: >> >>> 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" <joh...@wso2.com> wrote: >>> >>> >>> >>> On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <ga...@wso2.com> >>> wrote: >>> >>> >>> >>> On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <isha...@wso2.com> >>> wrote: >>> >>> Hi, >>> >>> On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <joh...@wso2.com> >>> wrote: >>> >>> >>> >>> On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <darsh...@wso2.com >>> > 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 <nuwan...@wso2.com> >>> 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 < >>> nuwan...@wso2.com> 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: darsh...@wso2.com <darsh...@wso2.com>* >>> *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: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: >>> +94717996791 >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >>> >>> >>> -- >>> Gayan Gunawardana >>> Software Engineer; WSO2 Inc.; http://wso2.com/ >>> Email: ga...@wso2.com >>> 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 >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Best Regards, > > Nuwandi Wickramasinghe > > Software Engineer > > WSO2 Inc. > > Web : http://wso2.com > > Mobile : 0719214873 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Asela ATL Mobile : +94 777 625 933 +358 449 228 979 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
