Friday, October 3, 2014

Trusted Master - Access Delegation Pattern


Let’s look at a large-scale enterprise that has a set of RESTful APIs. The APIs are hosted in different departments, and each department runs its own OAuth authorization server due to vendor incompatibilities in different deployments. Company employees are allowed to access these APIs via web applications while they’re behind the company firewall, regardless of the department to which they belong. All user data is stored in a centralized Active Directory, and all the web applications are connected to a centralized OAuth authorization server (which also supports OpenID Connect) to authenticate users.

The web applications need to access back-end APIs on behalf of the logged-in user. These APIs may come from different departments, each of which has its own authorization server. The company also has a centralized OAuth authorization server, and an employee having an access token from the centralized authorization server must be able to access any API hosted in any department.

You have a master OAuth authorization server and a set of secondary authorization servers. An access token issued from the master authorization server should be good enough to access any of the APIs under the control of the secondary authorization servers. In other words, the access token returned to the web application, as shown in step 3 of the above diagram, should be good enough to access any of the APIs. To make this possible, you need make the access token self-explanatory. Ideally, you should make the access token a JWT with the iss (issuer) field.

In step 4, the web application accesses the API using the access token; and in step 5, the API talks to its own authorization server to validate the token. The authorization server can look at the JWT header and find out whether it issued this token or if a different server issued it. If the master authorization server issued it, then the secondary authorization server can talk to the master authorization server’s OAuth introspection endpoint to find out more about the token. The introspection response specifies whether the token is active and identifies the scopes associated with the access token. Using the introspection response, the secondary authorization server can build an eXtensible Access Control Markup Language (XACML) request and call a XACML policy decision point (PDP). If the XACML response is evaluated to Permit, then the web application can access the API.

This is one of the ten API security patterns covered in my book Advanced API Security.

1 comments:

Benny said...

Even though rolex replica sale adheres towards the traditional Datejust style when it comes to appearance, it will function a few crucial technical breakthroughs which let it perform upon par along with replica watches choices. Whilst classic Rolex referrals existing a good unparalleled degree of background as well as collectability, they frequently absence the current functions which eventually improve fake watches as well as easy possession like a quick-set day perform. The significant function about the replica watches sale is actually it's utilization of Rolex's quality 3135 motion. Very first launched within 1988, the actual quality 3135 continues to be within manufacturing these days, as well as replica watches sale this in order to energy nearly all their own three-hand, day exhibiting wrist watches.