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 +358 449 228 979 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
