Hi Johann, Assuming this implementation is for C5,
Since API Manager REST APIs are written as micro services we thought of using msf4j security interceptors for securing REST apis. It uses introspect endpoint to get the authentication/authorization info. How the proposed implementation would help in this scenario? Thanks & Regards, Ishara Cooray Senior Software Engineer Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware 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? > > 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. Besides, this model is for C5 right? In which case I > assume there aren't cases where one tenant accesses services of another > tenant as such? > > 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 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
