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