Hi, Pushpalanka Jayawardhana
Software Engineer WSO2 Lanka (pvt) Ltd [image: Facebook]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.facebook.com%2Fpushpalanka> [image: Twitter]<http://s.wisestamp.com/links?url=http%3A%2F%2Ftwitter.com%2FPushpalanka> [image: LinkedIn]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.linkedin.com%2Fprofile%2Fview%3Fid%3D75175642%26trk%3Dtab_pro> [image: Blogger]<http://s.wisestamp.com/links?url=http%3A%2F%2Fpushpalankajaya.blogspot.com%2F> [image: SlideShare]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2FPushpalanka> Mobile: +94779716248 On Mon, Nov 11, 2013 at 12:43 PM, Venura Kahawala <ven...@wso2.com> wrote: > Hi Johann, > > > On Mon, Nov 11, 2013 at 12:15 PM, Johann Nallathamby <joh...@wso2.com>wrote: > >> Hi Venura, >> >> >> On Mon, Nov 11, 2013 at 10:46 AM, Venura Kahawala <ven...@wso2.com>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 >>> <prab...@wso2.com>wrote: >>> >>>> Hi Johann, >>>> >>>> Please find comment inline... >>>> >>>> On Mon, Nov 11, 2013 at 9:35 AM, Johann Nallathamby <joh...@wso2.com>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 <prab...@wso2.com >>>>> > 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 >>>>>> Architecture@wso2.org >>>>>> 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 >>>>> Architecture@wso2.org >>>>> 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 >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> Regards, >>> Venura >>> >>> -- >>> Senior Software Engineer >>> >>> Mobile: +94 71 82 300 20 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> 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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Senior Software Engineer > > Mobile: +94 71 82 300 20 > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
<<330.png>>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
