On Tue, Jan 24, 2017 at 1:24 PM, Nuwandi Wickramasinghe <[email protected]> wrote:
> 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 > Thanks a lot.. will give a try.. > > [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 > -- Thanks & Regards, Asela ATL Mobile : +94 777 625 933 +358 449 228 979 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
