On Mon, Nov 11, 2013 at 11:26 AM, Ishara Karunarathna <[email protected]>wrote:
> > > > On Mon, Nov 11, 2013 at 11:07 AM, Prabath Siriwardena <[email protected]>wrote: > >> On Mon, Nov 11, 2013 at 10:41 AM, Ishara Karunarathna >> <[email protected]>wrote: >> >>> Hi, >>> >>> 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. >>>> >>> In this scenario are there two set of roles >>> 1. Carbon Role >>> 2. Application Specific roles. ( Which can be seen only to the app.) >>> >> >> >> Carbon is the default app and all the current functionality will remain >> same. We need to have a separate API to pass the App identifier - or simply >> authenticates to the API with corresponding consumer API. We only need to >> go through roles of the corresponding app. >> >> Thanks & regards, >> -Prabath >> >> >> >>> >>> And If we going to evaluate permission for each app. we will have to go >>> through both roles ?? >>> >>> >>> >>>> >>>> >>>>> >>>>> 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. >>>> >>> > And in this scenario if each application have its own subset of trusted > IDPs, its better if we can assign a primary trusted IDP for a app, among > selected IDPs, > Then for a primary idp of each application we many not need to specify > the idp attribute. > +1 Thanks & regards, -Prabath > >>>> >>>>> >>>>> 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 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Ishara Karunarathna >>> Software Engineer >>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>> >>> email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94 >>> 718211678 >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Ishara Karunarathna > Software Engineer > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94 > 718211678 > > _______________________________________________ > 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
