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