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 <[email protected]>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 > [email protected] > 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* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
<<330.png>>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
