[Identity Server] Applications

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

[Identity Server] Applications

Prabath Siriwardena
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this.

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

_______________________________________________
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] Applications

Johann Nallathamby
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern. Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

Prabath Siriwardena
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,
Prabath


_______________________________________________
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] Applications

Ishara Karunarathna
Hi,

On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
In this scenario are there two set of roles
1. Carbon Role
2. Application Specific roles. ( Which can be seen only to the app.)

And If we going to evaluate permission for each app. we will have to go through both roles ??

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

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

_______________________________________________
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] Applications

venura
In reply to this post by Prabath Siriwardena
Hi,

Is this a continuation of what we discussed during the custom permissions feature code review?

Please see the comments inline...


On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.

+1 for this, This has to be done since if roles are not restricted to applications, an unintended user might get access to an application.
 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.

Here we can add another parameter to role management UI specifying the application.
 
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.

As an alternative to XACML we can use the new custom permission feature for this.
 
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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


Regards,
Venura

--
Senior Software Engineer

Mobile: +94 71 82 300 20


_______________________________________________
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] Applications

Prabath Siriwardena

On Mon, Nov 11, 2013 at 10:46 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

Is this a continuation of what we discussed during the custom permissions feature code review?

Yes...

Thanks & regards,
-Prabath 

Please see the comments inline...


On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.

+1 for this, This has to be done since if roles are not restricted to applications, an unintended user might get access to an application.
 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.

Here we can add another parameter to role management UI specifying the application.
 
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.

As an alternative to XACML we can use the new custom permission feature for this.
 
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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


Regards,
Venura

--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20


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




--
Thanks & Regards,
Prabath


_______________________________________________
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] Applications

Prabath Siriwardena
In reply to this post by Ishara Karunarathna
On Mon, Nov 11, 2013 at 10:41 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
In this scenario are there two set of roles
1. Carbon Role
2. Application Specific roles. ( Which can be seen only to the app.)


Carbon is the default app and all the current functionality will remain same. We need to have a separate API to pass the App identifier - or simply authenticates to the API with corresponding consumer API. We only need to go through roles of the corresponding app.

Thanks & regards,
-Prabath

 

And If we going to evaluate permission for each app. we will have to go through both roles ??

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,
Prabath


_______________________________________________
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] Applications

Ishara Karunarathna



On Mon, Nov 11, 2013 at 11:07 AM, Prabath Siriwardena <[hidden email]> wrote:
On Mon, Nov 11, 2013 at 10:41 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
In this scenario are there two set of roles
1. Carbon Role
2. Application Specific roles. ( Which can be seen only to the app.)


Carbon is the default app and all the current functionality will remain same. We need to have a separate API to pass the App identifier - or simply authenticates to the API with corresponding consumer API. We only need to go through roles of the corresponding app.

Thanks & regards,
-Prabath

 

And If we going to evaluate permission for each app. we will have to go through both roles ??

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.

And in this scenario if each application have its own subset of trusted IDPs, its better if we can assign a primary trusted IDP for a app, among selected IDPs,
Then for a primary idp of each application we many not need to specify the idp attribute.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,
Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

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

_______________________________________________
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] Applications

Prabath Siriwardena

On Mon, Nov 11, 2013 at 11:26 AM, Ishara Karunarathna <[hidden email]> wrote:



On Mon, Nov 11, 2013 at 11:07 AM, Prabath Siriwardena <[hidden email]> wrote:
On Mon, Nov 11, 2013 at 10:41 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
In this scenario are there two set of roles
1. Carbon Role
2. Application Specific roles. ( Which can be seen only to the app.)


Carbon is the default app and all the current functionality will remain same. We need to have a separate API to pass the App identifier - or simply authenticates to the API with corresponding consumer API. We only need to go through roles of the corresponding app.

Thanks & regards,
-Prabath

 

And If we going to evaluate permission for each app. we will have to go through both roles ??

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.

And in this scenario if each application have its own subset of trusted IDPs, its better if we can assign a primary trusted IDP for a app, among selected IDPs,
Then for a primary idp of each application we many not need to specify the idp attribute.

+1

Thanks & regards,
-Prabath
 
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,
Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,
Prabath


_______________________________________________
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] Applications

Johann Nallathamby
In reply to this post by Prabath Siriwardena
Hi Prabath,


On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.

I agree that applications should be able to define their own roles. 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.

Agree that we need to use the current user management UI to do this.

So I guess we are on the same page until here.. 
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.

Are you saying we need to ship carbon with a new system role? like publisher/subscriber in API Manager? I don't think we need to do that. If a user who is registering applications needs to manage roles he should be given appropriate Carbon permissions to do that by the tenant admin. It is simple as that.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.

Agreed. 
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

I think we are on the same page here. May be I wasn't clear. Yes, the HR department can select which user stores can access its application.
What I meant earlier was we don't have to allow the application owner to create/define a new user store which is the responsibility of the tenant admin.


 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.

I think it is very much relevant here. Applications should be able to select the form of authentication they want. We've agreed that applications should be able to select user stores and trusted IdPs. Both of them play vital roles in authentication.

As a web app developer in a tenant I would upload my webapp, and select the authenticators I would like to engage. E.g. let's say there is username/password authenticator and SAML SSO authenticator. I write a webapp, upload it and select SAML SSO authenticator only. Then my choice of Trusted IdP is useful to redirect the user to the correct IdP. If I select only username/password authenticator then my selection of Trusted IdP is not useful (at least for authentication) because the system is authenticating with the underlying user store. In that my choice of user stores are useful.
 
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...

So this is just the usual role/permission based authorization we do. It is not fine grained authorization. In that case why can't we do it like what we currently have with AuthorizationManager.. the DB based approach? Why do you intend to generate XACML policies for this? Because when comparing authorization with DB vs XACML, I think DBs will outperform XACML for role simple role based authorization atleast.
 
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application.
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Yes, we don't have to encrypt the consumer key, but still I feel we can use a different identifier to uniquely identify the application rather than consumer key. There is no reason to consider OAuth special consideration here.  Or else if we could have user defined names that are meaningful as the consumer key, like "Johann'sPlaygroundApp", and use the same as entity Id when registering a SAML SSO service provider, and wherever we uniquely identify the application that also seems fine with me. In fact our APIs allow us to specify consumer keys and I have seen other products that allows us to do this. Only consumer secrets are auto generated. 

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

Johann Nallathamby
In reply to this post by venura
Hi Venura,


On Mon, Nov 11, 2013 at 10:46 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

Is this a continuation of what we discussed during the custom permissions feature code review?

Please see the comments inline...


On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.

+1 for this, This has to be done since if roles are not restricted to applications, an unintended user might get access to an application.

My notion is that:

An application (developer) can restrict access to his/her application based on
- user stores
- trusted IdPs
- roles
- users (if this is possible then unwanted users cannot get access to the application)

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.

Here we can add another parameter to role management UI specifying the application.

If we agree with what I have mentioned above we don't need any change in this UI. We only need to list existing userstores, trusted IdPs, roles and user in the new App-Mgt UI and the application developer will choose from that list.

To reiterate, managing roles should be a separate concern which won't change from what we have now. Whether the app developer is able to do that depends on the Carbon permissions he/she has.
 
 
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.

As an alternative to XACML we can use the new custom permission feature for this.

Actually this what I mentioned previously as DB based approach. I think we need to weigh the pros and cons and come to a decision. 
 
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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


Regards,
Venura

--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20


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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

Johann Nallathamby
In reply to this post by Ishara Karunarathna
Hi Ishara,


On Mon, Nov 11, 2013 at 11:26 AM, Ishara Karunarathna <[hidden email]> wrote:



On Mon, Nov 11, 2013 at 11:07 AM, Prabath Siriwardena <[hidden email]> wrote:
On Mon, Nov 11, 2013 at 10:41 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
In this scenario are there two set of roles
1. Carbon Role
2. Application Specific roles. ( Which can be seen only to the app.)


Carbon is the default app and all the current functionality will remain same. We need to have a separate API to pass the App identifier - or simply authenticates to the API with corresponding consumer API. We only need to go through roles of the corresponding app.

Thanks & regards,
-Prabath

 

And If we going to evaluate permission for each app. we will have to go through both roles ??

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.

And in this scenario if each application have its own subset of trusted IDPs, its better if we can assign a primary trusted IDP for a app, among selected IDPs,
Then for a primary idp of each application we many not need to specify the idp attribute.

+1
 
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,
Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

Johann Nallathamby
In reply to this post by Ishara Karunarathna



On Mon, Nov 11, 2013 at 10:41 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
In this scenario are there two set of roles
1. Carbon Role
2. Application Specific roles. ( Which can be seen only to the app.)

And If we going to evaluate permission for each app. we will have to go through both roles ??

I don't think we need to differentiate Carbon roles and Application specific roles. Application specific roles could be a subset of Carbon roles. The application developer who registers the application would select a subset roles allowed to use his app from the App-Mgt UI. 


 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

Johann Nallathamby
In reply to this post by Prabath Siriwardena



On Mon, Nov 11, 2013 at 11:07 AM, Prabath Siriwardena <[hidden email]> wrote:
On Mon, Nov 11, 2013 at 10:41 AM, Ishara Karunarathna <[hidden email]> wrote:
Hi,

On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.
In this scenario are there two set of roles
1. Carbon Role
2. Application Specific roles. ( Which can be seen only to the app.)


Carbon is the default app and all the current functionality will remain same. We need to have a separate API to pass the App identifier - or simply authenticates to the API with corresponding consumer API. We only need to go through roles of the corresponding app.

+1 for overloaded API passing the identifier. This is what I had in mind as well. What we need to decide is the model we are going to store and evaluate.. DB tables vs. XACML policy.
 

Thanks & regards,
-Prabath

 

And If we going to evaluate permission for each app. we will have to go through both roles ??

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Ishara Karunarathna
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:%2B94%20718211678" value="+94718211678" target="_blank">+94 718211678

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




--
Thanks & Regards,
Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

venura
In reply to this post by Johann Nallathamby
Hi Johann,


On Mon, Nov 11, 2013 at 12:15 PM, Johann Nallathamby <[hidden email]> wrote:
Hi Venura,


On Mon, Nov 11, 2013 at 10:46 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

Is this a continuation of what we discussed during the custom permissions feature code review?

Please see the comments inline...


On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.

+1 for this, This has to be done since if roles are not restricted to applications, an unintended user might get access to an application.

My notion is that:

An application (developer) can restrict access to his/her application based on
- user stores
- trusted IdPs
- roles
- users (if this is possible then unwanted users cannot get access to the application)

I'm not clear on this approach. What you are telling here is, if I (developer) select a role for my application, then no other application developer should be able to get the same for their applications? If we do that we can avoid changes to the current UI. But we need to identify a method to avoid concurrent modification to the same role. May be this a rare case, but possible. What is the chance of you and me (both application developers) assign the same role to different applications?
 

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.

Here we can add another parameter to role management UI specifying the application.

If we agree with what I have mentioned above we don't need any change in this UI. We only need to list existing userstores, trusted IdPs, roles and user in the new App-Mgt UI and the application developer will choose from that list.

To reiterate, managing roles should be a separate concern which won't change from what we have now. Whether the app developer is able to do that depends on the Carbon permissions he/she has.
 
 
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.

As an alternative to XACML we can use the new custom permission feature for this.

Actually this what I mentioned previously as DB based approach. I think we need to weigh the pros and cons and come to a decision. 
 
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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


Regards,
Venura

--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20


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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Senior Software Engineer

Mobile: +94 71 82 300 20


_______________________________________________
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] Applications

Prabath Siriwardena
In reply to this post by Johann Nallathamby



On Mon, Nov 11, 2013 at 11:47 AM, Johann Nallathamby <[hidden email]> wrote:


Yes, we don't have to encrypt the consumer key, but still I feel we can use a different identifier to uniquely identify the application rather than consumer key. There is no reason to consider OAuth special consideration here.  

Do not relate this to Oauth. We need to have unique identifier to the application. So that is a client id - and it will become the client id as when oauth enabled. Almost all the application will have oauth enabled by default.

Thanks & regards,
-Prabath
 
Or else if we could have user defined names that are meaningful as the consumer key, like "Johann'sPlaygroundApp", and use the same as entity Id when registering a SAML SSO service provider, and wherever we uniquely identify the application that also seems fine with me. In fact our APIs allow us to specify consumer keys and I have seen other products that allows us to do this. Only consumer secrets are auto generated. 

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,
Prabath


_______________________________________________
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] Applications

Pushpalanka Jayawardhana
In reply to this post by venura
Hi,

Pushpalanka Jayawardhana

Software Engineer

WSO2 Lanka (pvt) Ltd

Facebook Twitter LinkedIn Blogger SlideShare
Mobile: +94779716248


On Mon, Nov 11, 2013 at 12:43 PM, Venura Kahawala <[hidden email]> wrote:
Hi Johann,


On Mon, Nov 11, 2013 at 12:15 PM, Johann Nallathamby <[hidden email]> wrote:
Hi Venura,


On Mon, Nov 11, 2013 at 10:46 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

Is this a continuation of what we discussed during the custom permissions feature code review?

Please see the comments inline...


On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.

+1 for this, This has to be done since if roles are not restricted to applications, an unintended user might get access to an application.

My notion is that:

An application (developer) can restrict access to his/her application based on
- user stores
- trusted IdPs
- roles
- users (if this is possible then unwanted users cannot get access to the application)

I'm not clear on this approach. What you are telling here is, if I (developer) select a role for my application, then no other application developer should be able to get the same for their applications? If we do that we can avoid changes to the current UI. But we need to identify a method to avoid concurrent modification to the same role. May be this a rare case, but possible. What is the chance of you and me (both application developers) assign the same role to different applications?
With what I have understood, I guess this can be solved if we prefix each role that is related with an application, with the appID or something that is unique to that application. We can initiate these roles from existing roles, but after it is related to an application, it will have an independent existence. In AF, they are using this prefixing to keep roles within an application.
 

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.

Here we can add another parameter to role management UI specifying the application.

If we agree with what I have mentioned above we don't need any change in this UI. We only need to list existing userstores, trusted IdPs, roles and user in the new App-Mgt UI and the application developer will choose from that list.

To reiterate, managing roles should be a separate concern which won't change from what we have now. Whether the app developer is able to do that depends on the Carbon permissions he/she has.
 
 
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.

As an alternative to XACML we can use the new custom permission feature for this.

Actually this what I mentioned previously as DB based approach. I think we need to weigh the pros and cons and come to a decision. 
 
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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


Regards,
Venura

--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20


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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20


_______________________________________________
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] Applications

Johann Nallathamby
In reply to this post by Prabath Siriwardena



On Mon, Nov 11, 2013 at 1:01 PM, Prabath Siriwardena <[hidden email]> wrote:



On Mon, Nov 11, 2013 at 11:47 AM, Johann Nallathamby <[hidden email]> wrote:


Yes, we don't have to encrypt the consumer key, but still I feel we can use a different identifier to uniquely identify the application rather than consumer key. There is no reason to consider OAuth special consideration here.  

Do not relate this to Oauth. We need to have unique identifier to the application. So that is a client id - and it will become the client id as when oauth enabled. Almost all the application will have oauth enabled by default.

Then it should be the same for SAML SSO as well right? All applications should be SAML SSO enabled by default..?
 

Thanks & regards,
-Prabath
 
Or else if we could have user defined names that are meaningful as the consumer key, like "Johann'sPlaygroundApp", and use the same as entity Id when registering a SAML SSO service provider, and wherever we uniquely identify the application that also seems fine with me. In fact our APIs allow us to specify consumer keys and I have seen other products that allows us to do this. Only consumer secrets are auto generated. 

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,
Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

Johann Nallathamby
In reply to this post by venura



On Mon, Nov 11, 2013 at 12:43 PM, Venura Kahawala <[hidden email]> wrote:
Hi Johann,


On Mon, Nov 11, 2013 at 12:15 PM, Johann Nallathamby <[hidden email]> wrote:
Hi Venura,


On Mon, Nov 11, 2013 at 10:46 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

Is this a continuation of what we discussed during the custom permissions feature code review?

Please see the comments inline...


On Mon, Nov 11, 2013 at 9:58 AM, Prabath Siriwardena <[hidden email]> wrote:
Hi Johann,

Please find comment inline...

On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[hidden email]> wrote:
Hi Prabath,

+1 for the concept. Some concerns and thoughts inline.. bear with me for my lengthy verbose arguments.. 


On Mon, Nov 11, 2013 at 3:12 AM, Prabath Siriwardena <[hidden email]> wrote:
1. What is an Application under the context of Identity Server ?

Its a consumer of identity attributes, roles (and groups), authentication methods/ policies and authorization policies. In practice, this could be a web application,mobile application - or even a desktop application.

- Identity attributes

A given user can be allowed to maintain his own set of attributes against different registered Applications. (multiple profiles)

This should be a separate thread of discussion, but just so that we are on the same page here, for this we need to have the multiple profiles working with all types user stores. Currently it works with only JDBC. As I understand there are problems with representing multiple values for attributes in a standard manner in all kinds of LDAPs. Am I right? I guess we need to figure out a way of supporting this.

Yes. The underlying user store should support this. We can support by default for both LDAP and JDBC.
 
 

- Permission / Roles

A given Application can maintain its own set of permissions with the Identity Server. That is, a given application can maintain its own set of resources and actions. For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today.

Applications can create their own permissions of course, but do we allow them do define their own roles as well or do they select roles from existing roles of the tenant and assign permissions to them?

Yes. Application should be allowed define their own roles Those out side the permission model of Carbon.

+1 for this, This has to be done since if roles are not restricted to applications, an unintended user might get access to an application.

My notion is that:

An application (developer) can restrict access to his/her application based on
- user stores
- trusted IdPs
- roles
- users (if this is possible then unwanted users cannot get access to the application)

I'm not clear on this approach. What you are telling here is, if I (developer) select a role for my application, then no other application developer should be able to get the same for their applications? If we do that we can avoid changes to the current UI. But we need to identify a method to avoid concurrent modification to the same role. May be this a rare case, but possible. What is the chance of you and me (both application developers) assign the same role to different applications?

I never said role should be restricted to one application. In fact that is what I am trying to avoid. Roles will be common to all applications, but permissions to each role will be specific to an application.

If you and me both are developers we both can consume the restrict users based on the same role.
E.g. if the role trainee has 3 users user1, user2 and user3 and you as the application developer have selected your application to be restricted to trainee role and I do the same thing, then we both allow the same set of users to access our applications. But the privileges each user has in our applications are different based on the permissions of our applications.  
 

 
 

Allowing the creation of roles in this app-mgt UI would duplicate role-mgt functionality and managing roles should be an independent concern.

We do not need to have separate UIs. We have to reuse currently used user management UI. Carbon is once again just another application.

Here we can add another parameter to role management UI specifying the application.

If we agree with what I have mentioned above we don't need any change in this UI. We only need to list existing userstores, trusted IdPs, roles and user in the new App-Mgt UI and the application developer will choose from that list.

To reiterate, managing roles should be a separate concern which won't change from what we have now. Whether the app developer is able to do that depends on the Carbon permissions he/she has.
 
 
 
Whether the application developer can create roles and assign users to them depends on whether he has permissions to do role-mgt operations in the UI we currently have. In my opinion this new feature should only look at assigning custom permissions to existing roles in the tenant. Creating roles and assigning users to them by default should be the responsibility of the tenant admin, which he can delegate to the application (user registering the app) by assigning the required permissions to him.

There needs to be new App Administration role - in the Carbon.
 


- Authentication Policies.

A given Application can have its own set of trusted SAML2 IdPs + SAML response requirements(what attributes should be there, signed or not). It's own OAuth client key/secret. Its own WS-trust/STS policies. Also it can have its own user store.

With regard to Trusted IdPs and user stores again I have the same concern as above..

When you say "Application can have its own set of" I am thinking you mean "can select a subset from what is available in the tenant" right? Because the model we have right now is, the tenant admin will decide on the user stores to be configured and IdPs to be trusted for the tenant. And if applications (users who are registering applications) can select a subset of those, the model will easily fit in. But if you are thinking of defining user stores and trusted IdPs for applications itself, then the model would go through some radical changes.

Application Admins can select a subset of user stores available to them.
 

E.g. I am not sure if having user stores per application makes sense. For me what makes sense is applications registrants restricting the use of their applications by user stores available in the tenant. I think it is valid even to be able to restrict usage by users/roles. 

No this has use cases. Its an option the Application decide whether they want it or not. IS can provide an aggregated view of set of user stored belong different departments. But - HR can have an application that only needs to get users from its own user store - not from others.

 

To add to this I think we can define an authenticator chain per application according to the new authentication framework. Internally we can serialize this into a XML file like we currently have and store it.

Ideally we should keep authenticator away from this.
 


- Authorization Policies

This is how we relate available permissions for an Application, to its roles. This can be finally represented in XACML.

I am not quite sure I understood the above statement.

This is as simple as defining permission for roles defined for its own application. Application can ask whether user is authorized to access resource with a given action.

As an alternative to XACML we can use the new custom permission feature for this.

Actually this what I mentioned previously as DB based approach. I think we need to weigh the pros and cons and come to a decision. 
 
 

However, if you are thinking of defining XACML policies per application and do authorization against it, my suggestion is to have a PolicySet per application. Under which each application can define multiple policies. 

We need to keep XACML underneath. Not exposed to the user - so yes.. this is implementation details...
 


One more thing I can add to this list is defining identity management parameters per application. E.g. the application callback URL to which the temporary code for password reset is sent should be per application. Now it is a global config.

+1
 
 

2. How does this relate to multi-tenancy ?

A given tenant can have its own set of Applications.

3. How does this work with Carbon ?

Carbon it self is just another registered Application.

I am a little unclear with above statement and the one you have made under Permission/Roles: "For IS - Carbon is just another application - and its permissions / roles will be maintained as it is today"

Does this mean we need to change the current carbon permission model to follow the new model or not? (I am thinking about code and data)

If Carbon is looked at as just another application we need to change the way permissions are stored at DB level following this new application based DB schema. But existing Carbon permissions get stored in a different schema in user management DB.

Currently the Carbon authorization is done via 'AuthorizationManager'. How does the new Application based Authorization component fit here? Do we modify the Authorization Manger component to support this and have a single API or write a completely new component for this and have a different API as well.

We don't need to change anything there. Carbon can be considered as the default application. 
 


4. Don't we already have the Application concept in IS ?

Yes.. we do.. but that is scattered across. In OAuth - we uniquely identify an application from the client key. When define a SAML2 Service Provider - we identify it by the EntityId. We don't have such concept for roles, permission, authorization policies. Idea is to unify this across the platform.

The unique identifier of an application would be the client key. And for the administrative operations we need to provider an API - which is protected with OAuth.

I would like to see a separate unique identifier other than the consumer key. Of course consumer key is unique so is the SAML entity ID, but I won't like to see the consumer key being written all over the database for referential integrity. And we do support encryption of the consumer key, so I don't think it is good idea to have this as unique identifier.

We do not need to encrypt the consumer key. We only need to encrypt the consumer secret.

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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


Regards,
Venura

--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20


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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20


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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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] Applications

Prabath Siriwardena
In reply to this post by Johann Nallathamby
All applications need not to have SAML enabled by default . OAuth is used to secure all the REST APIs to administer the Apps... and other related APIs.. that's why we need OAuth by default...

Thanks & regards
-Prabath

Sent from my mobile device

On Nov 11, 2013, at 1:06 PM, Johann Nallathamby <[hidden email]> wrote:




On Mon, Nov 11, 2013 at 1:01 PM, Prabath Siriwardena <[hidden email]> wrote:



On Mon, Nov 11, 2013 at 11:47 AM, Johann Nallathamby <[hidden email]> wrote:


Yes, we don't have to encrypt the consumer key, but still I feel we can use a different identifier to uniquely identify the application rather than consumer key. There is no reason to consider OAuth special consideration here. <335.png> 

Do not relate this to Oauth. We need to have unique identifier to the application. So that is a client id - and it will become the client id as when oauth enabled. Almost all the application will have oauth enabled by default.

Then it should be the same for SAML SSO as well right? All applications should be SAML SSO enabled by default..?
 

Thanks & regards,
-Prabath
 
Or else if we could have user defined names that are meaningful as the consumer key, like "Johann'sPlaygroundApp", and use the same as entity Id when registering a SAML SSO service provider, and wherever we uniquely identify the application that also seems fine with me. In fact our APIs allow us to specify consumer keys and I have seen other products that allows us to do this. Only consumer secrets are auto generated. 

Thanks & regards,
-Prabath
 
 

5. Would this change the Identity Server Management Console UI ?

Yes. We need to have a tab for defining and listing Applications. Also other tabs also need to absorb the Application concept while grouping.

6. How does this differ from the Application we create in API Manager ?

It's the same + more capabilities.

7. How does this relate to Web Applications we host in Application Server ?

Its the same. You define QoS parameters for those applications from this. 

Ideas, thoughts, questions mostly welcome..

Thanks & regards,
-Prabath

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,

Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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




--
Thanks & Regards,
Prabath

Mobile : <a href="tel:%2B94%2071%20809%206732" value="+94718096732" target="_blank">+94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

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




--
Thanks & Regards,

Johann Dilantha Nallathamby
Senior Software Engineer
Integration 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
123