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