Hi Asela, In that case you need to customize PostAuthenticationHandler implementation. Default implementation is found in [1].
Please note that there's a bug in extension point naming reported in [2]. Therefore when configuring the extension class, you will have give the extension class as an <AuthorizationHandler> under <Extensions> in application-authentication.xml [1] https://github.com/wso2/carbon-identity-framework/blob/master/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/request/impl/DefaultPostAuthenticationHandler.java [2] https://wso2.org/jira/browse/IDENTITY-5575 best regards Nuwandi On Tue, Jan 24, 2017 at 12:42 PM, Asela Pathberiya <[email protected]> wrote: > > > On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe < > [email protected]> wrote: > >> Hi Asela, >> >> This does not work in 5.3.0. >> >> IS will pop up for the mandatory claims requested by the Service Provider >> if they are not sent by the federated authenticator. But the claims >> provided by the user at this step are not persisted for federated users, >> even if they are provisioned to IS. I think we have missed that part and >> better to persist these values in provisioned user profile. >> >> However, the mandatory claim configuration in Service Provider indicates >> this claim is mandatory to access that particular SP. Should we have a >> different configuration to define mandatory claims for provisioning ? >> > > Yes. it may be different.. There are required claims based on the > provisioning user store. Basically Mandatory claims for JIT Can we fix > this for future release ? > > However; if i want to achieve this using WSO2IS 5.3.0 what is extension > to customize ? Is it JIT provisioning handler or some other ? (Assume > that i want to JIT claims which are popup/requested by SP) > > Thanks, > Asela. > > >> >> thanks >> Nuwandi >> >> On Mon, Jan 23, 2017 at 6:41 PM, Asela Pathberiya <[email protected]> wrote: >> >>> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 <[email protected]> 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" <[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 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> ATL >>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>> +358 449 228 979 >>> >>> http://soasecurity.org/ >>> http://xacmlinfo.org/ >>> >> >> >> >> -- >> >> Best Regards, >> >> Nuwandi Wickramasinghe >> >> Software Engineer >> >> WSO2 Inc. >> >> Web : http://wso2.com >> >> Mobile : 0719214873 >> > > > > -- > Thanks & Regards, > Asela > > ATL > Mobile : +94 777 625 933 <+94%2077%20762%205933> > +358 449 228 979 > > http://soasecurity.org/ > http://xacmlinfo.org/ > -- Best Regards, Nuwandi Wickramasinghe Software Engineer WSO2 Inc. Web : http://wso2.com Mobile : 0719214873
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
