Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Nuwandi Wickramasinghe
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


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Nuwandi Wickramasinghe
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.

thanks and best regards
Nuwandi

On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <[hidden email]> 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


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Darshana Gunawardana
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].

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.

[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 <[hidden email]> 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.

thanks and best regards
Nuwandi

On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;nuwandiw@wso2.com&#39;);" target="_blank">nuwandiw@...> 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: [hidden email]
Mobile: +94718566859
Lean . Enterprise . Middleware



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Nuwandi Wickramasinghe


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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].

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?
         - yes. In this case it will retrieve saved claims from local account.

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.

[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 <[hidden email]> 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.

thanks and best regards
Nuwandi

On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
Lean . Enterprise . Middleware





--

Best Regards,

Nuwandi Wickramasinghe

Software Engineer

WSO2 Inc.

Web : http://wso2.com

Mobile : 0719214873


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Ishara Karunarathna
In reply to this post by Darshana Gunawardana
Hi,

On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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].
+1

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.
I think in the above case if we have anable jit for that federated authenticator lets set the option to store those attributes.

-Ishara

[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 <[hidden email]> 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.

thanks and best regards
Nuwandi

On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
Lean . Enterprise . Middleware





--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: +94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Johann Nallathamby
In reply to this post by Darshana Gunawardana


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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.
 

thanks and best regards
Nuwandi

On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
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

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Ishara Karunarathna
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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.
 

thanks and best regards
Nuwandi

On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: +94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Gayan Gunawardana


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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.
 

thanks and best regards
Nuwandi

On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Johann Nallathamby


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Harsha Thirimanna - WSO2, Inc.

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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Jochen Traunecker
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?

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 ?

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 ....

Thanks,
Jochen

Harsha Thirimanna <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Nuwandi Wickramasinghe
In reply to this post by Harsha Thirimanna - WSO2, Inc.


On Wed, Nov 2, 2016 at 6:30 AM, Harsha Thirimanna <[hidden email]> wrote:

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 ?

If the SP configuration is changed to have more mandatory claims during the user is logged in to the same SP, next time when he try to login to the app using a different tab, he will be prompted to provide new mandatory claims though he doesn't have to provide credentials (since he has a logged in session)


On Nov 2, 2016 12:07 AM, "Johann Nallathamby" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Nuwandi Wickramasinghe
In reply to this post by Jochen Traunecker
Sorry for the late reply. Please find the inline comments.

thanks and regards.

On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="m_-5725406555076858689gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="m_-5725406555076858689gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Asela Pathberiya
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Nuwandi Wickramasinghe
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 ?

thanks
Nuwandi

On Mon, Jan 23, 2017 at 6:41 PM, Asela Pathberiya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Asela Pathberiya


On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Nuwandi Wickramasinghe
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


best regards
Nuwandi

On Tue, Jan 24, 2017 at 12:42 PM, Asela Pathberiya <[hidden email]> wrote:


On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="m_-350390396504845678m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="m_-350390396504845678m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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 : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Asela Pathberiya


On Tue, Jan 24, 2017 at 1:24 PM, Nuwandi Wickramasinghe <[hidden email]> 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..
 

On Tue, Jan 24, 2017 at 12:42 PM, Asela Pathberiya <[hidden email]> wrote:


On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="m_1008577820987781160m_-350390396504845678m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="m_1008577820987781160m_-350390396504845678m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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 : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

Asela Pathberiya


On Tue, Jan 24, 2017 at 3:17 PM, Asela Pathberiya <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 1:24 PM, Nuwandi Wickramasinghe <[hidden email]> 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..

I could implement to persist the mandatory claims by creating an automatic associations [1] with 5.3.0.  Hope; this will properly fixed with next release.

However;  in DefaultPostAuthenticationHandler.java,  there are some private methods, it is good to make them protected.  Then it is easy to extend. 

 
 

On Tue, Jan 24, 2017 at 12:42 PM, Asela Pathberiya <[hidden email]> wrote:


On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana <[hidden email]> wrote:


On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby <[hidden email]> wrote:


On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B94718566859" value="+94718566859" class="gmail-m_-4833899567050688601m_1008577820987781160m_-350390396504845678m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94718566859
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



--
Ishara Karunarathna
Associate Technical Lead

WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94717996791" value="+94717996791" class="gmail-m_-4833899567050688601m_1008577820987781160m_-350390396504845678m_8409850515001270190m_-512589674712128436m_-3119526414754658729m_-5725406555076858689gmail_msg" target="_blank">+94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/



--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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 : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +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 : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+94 777 625 933
             +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/



--
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
             +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture