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
