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 <[email protected]>wrote: > Hi Johann, > > Please find comment inline... > > On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <[email protected]>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 <[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. >> > > 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 >>> [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>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > Regards, Venura -- Senior Software Engineer Mobile: +94 71 82 300 20
<<330.png>>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
