Hi Venura,
On Mon, Nov 11, 2013 at 10:46 AM, Venura Kahawala <[email protected]> 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 <[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. > 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 >>>> [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 > > > _______________________________________________ > 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
