Hi Nuwan, On Thu, Nov 10, 2016 at 11:40 AM, Nuwan Dias <[email protected]> wrote:
> Hi Johann, > > I think it would help if you can come up with a sequence diagram which > explains the exact points in the authentication/authorization process and > what they actually do :). > > Although we decide the granularity of our resource permissions, when it > comes to customer deployments the granularity we define would be too > coarse-grained for some customers and too fine-grained for some others. > Basically the carbon permissions strings we define may or may not be > sufficient. They may want to define their own and configure. And what > customers have at their end are users and their groups. So what they would > at the end of the day do is to map their user groups with these resources > directly or indirectly. Can you explain the steps needed to be performed by > a customer to define their own carbon permission (assume they require a new > one) and how they would map their groups to these resources? > If custom permissions are required that can be done in IS. We have the ability to add custom permission for each service provider. The service provider you create for this doesn't actually have to correspond to any actual service provider. We will create it only for the purpose of defining custom permissions. Once they are defined they will appear as regular permissions in the permission tree and then admin user can assign them to roles as required. I understand, Service Provider Mgt component is not part of all the products by default, therefore it may b difficult to create these custom permissions in other products if they don't have the Service Provider Mgt feature. But the expectation of my original mail was not for users to define their own permissions for each resource. But we will define a fine grain enough permission for each resource (can take the same approach we discussed for C5) we expect to have authorization. This will be fixed for a (resource + action). The way we feed this resource + action to permission mapping to the authorization module is by declaring it in identity.xml as illustrated in my original mail. The only part users will do is assign the permission we have defined to roles appropriately. In this approach it is not required for user to define custom permissions. Only requirement is to be able to expand the permission tree with some new permissions, which can be done by writing a UI bundle with component.xml, or calling registry APIs and create resources accordingly. > > When it comes to REST API resources, having /t/tenantdomain is not > natural. Therefore I don't think we should mandate having the tenant domain > in the resource URI. > Currently we are checking to see if it is technically possible to define tenant domain as follows in C4. E.g. OAuth2 Token Endpoint as - https://localhost:9443/wso2.com/oauth2/token If this is possible I think you problem will be solved. Otherwise I am afraid we don't have a better option. > Besides, this model is for C5 right? > In fact the requirement came for us in IS 5.3.0 which is on C4. And I initiated this thinking of C4 only. For C5 I think we have already solved this problem to great extent using CXF interceptors. IIRC it follows very similar model to what I have proposed here, except that the permissions are defined for each (resource + operation) declaratively using annotations in code itself. Even though it seems less flexible compared to declaring it in a config file, I think it should be fine because, users are not going to be changing the permissions required to have access to a particular (resource + operation). > In which case I assume there aren't cases where one tenant accesses > services of another tenant as such? > Yes, in C5 we don't have that case for "Resource access across tenants". But still we have the second requirement mentioned above, which is "Self access and Delegated access for the same resource" > Thanks, > NuwanD. > > On Thu, Nov 10, 2016 at 9:21 AM, Johann Nallathamby <[email protected]> > wrote: > >> Authentication and authorization are common requirements for Rest APIs. >> Since SOAP was the common API standard so far in C4, when it comes to Rest >> APIs, each product has implemented its own authentication and authorization >> mechanism. In Identity server so far we haven't had a common authentication >> and authorization module for Rest APIs. SCIM and OAuth2 Token endpoints >> were the only Rest APIs in IS so far which had built in authentication and >> authorization. >> >> For IS 5.3.0 we added more Rest APIs and needed a common authentication >> and authorization module which is externalized, extensible and >> configuration driven for all the authorization requirements we have had so >> far. >> >> The approach we took for authentication is to write a OSGi service and >> expose a Java API, which takes in a defined object model which will do the >> authentication and return the result. Behind the service API we have >> provided an SPI to plug-in authenticators such as Basic Auth, OAuth2, etc. >> The clients of this API can be a cxf filter, cxf interceptor, servlet >> filter or tomcat valve. You can use which ever you want depending on your >> use case. We can use the relevant configuration files for filters, >> interceptors, valves, etc. to configure the context paths which need >> authentication for. >> >> Currently we have 3 authenticator implementations. >> 1. Username/Password >> 2. OAuth2 >> 3. X509 - >> Although technically it is possible to authenticate the end user using >> X509 certificates, by having a certificate per user and authenticating the >> user using the CN of the certificate, practically we don't use X509 >> authentication that way. How we use it in practice is, >> >> A. Client certificate authentication without username >> >> This approach is used when there is no end user based authorization >> requirements. As long as the client who is sending the request is trusted >> and valid. E.g. >> >> B. Client certificate authentication with username (trusted sub-system) >> >> This is required when there are authorization requirements based on end >> user. Basically we trust the client that it has authenticated the user >> successfully and IS will only do the authorization for the user. >> >> >> Another two authenticators in the pipeline are "System User" and "Signed >> JWT" authenticator. "System User" authenticator means having couple of >> system wide usernames and passwords that is configured in a text file and >> secured, which client can authenticate with. >> >> For authorization we have provided another OSGi service API, which will >> also takes in a defined object model and returns the authorization result. >> The authorization rules can be configured in identity.xml as follows. >> <ResourceAccessControl> >> <Resource context="/api/identity/*" secured="true" >> http-method="all"> >> <Permissions>/permission/admin/login</Permissions> >> </Resource> >> <Resource context="/api/test" secured="true" >> http-method="put,post"> >> <Permissions>/permission/admin/test</Permissions> >> </Resource> >> </ResourceAccessControl> >> >> Like with authentication clients of this authorization API can be a CXF >> filter, CXF interceptor, servlet filter or tomcat valve. >> >> In addition to the above there are two more broad authorization >> requirements which are are yet to implement. >> >> 1. Resource access across tenants - >> >> We called it "SaaS" mode in previous releases. It was available for >> certain admin SOAP APIs in IS. However this has come as a generic >> requirement for all admin APIs. However we faced some difficulties in >> implementing this for SOAP services because we don't have a standard model >> to represent the tenant and user which the resource belongs to. >> >> For Rest APIs this is possible. We can specify tenant domain as part of >> the URL. E.g. api/identity/user/t/wso2.com where "wso2.com" is the >> tenant. >> >> 2. "Self access" and "Delegated access" for the same resource >> >> Users can access/update their own resources without any authorization by >> just doing authentication only. This is known as "Self access". >> One user in a tenant should be able to do actions on another user's >> behalf. This is known as "Delegated access". This also was supported for >> certain admin SOAP APIs in previous IS. For this we specify a distinct >> permission for users to access/update resources of other users. >> >> To implement this requirement we need to specify two parameterized >> permissions in the authorization module. One for "self access" and one for >> "delegated access". To identify whether the request is a "self access" one >> or a "delegated access" one, we need to specify the user in the Rest URL. >> E.g. api/identity/user/t/wso2.com/hr/john where "wso2.com" is the >> tenant, "hr" is the userstore domain and "john" is the username. >> >> If you are going to secure Rest APIs in your product, please check this >> implementation and see if it satisfies your requirement and give us >> feedback where it can be improved. >> >> [1] https://github.com/wso2-extensions/identity-carbon-auth-rest >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Technical Lead & Product Lead of WSO2 Identity Server >> Governance Technologies Team >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance 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
