OAuth is an authorization framework that allows a resource owner to grant permission to access their resources without sharing their credentials with a third party. Traditionally in client-server authentication model, the client uses its credentials to access its resources hosted by the server. OAuth introduces a third role called the resource owner. In this model, the client (which is not the resource owner, but is acting on its behalf) requests access to resources controlled by the resource owner, but hosted by the server.
Below figure shows OAuth in Datapower,
How to Use It?
To use the OAuth protocol, we need an AAA policy. The AAA policy must be defined in a processing rule of Web Token Service or Multi-Protocol Gateway.After successfully generating an access token, processing returns a node set that becomes part of the JSON object that contains the access token and optionally a refresh token.
- When configured through a Web Token Service, the service supports as authorization server endpoints
- When configured through a Multi-Protocol Gateway, the service supports as authorization server endpoints and enforcement point for resource servers.
Types of Protocol Flow
- Three Legged Flow – There are 3 entities namely the resource owner, an OAuth client who wants to access the resource, the resource server. The resource owner does not share its credentials to client instead it gives authorization grant and a client ID by an authorization service. Using authorization grant, OAuth client request an access token from authorization service to access the resource on resource server.
- Two Legged Flow – There are only 2 entities where the resource owner and OAuth client overlaps. The client needs resource owner credentials or a client credentials grant type. There are four credential grant type scenarios.
1. Implementation (Two legged Flow) through WTS (Grant type scenario- resource owner password credentials)
This scenario involves exchanging the resource owner’s username and password for an access token and make use of that token to access resources, which means the client possess the resource owner’s credentials. Client application sends a token request containing the resource owner username and password as well as its information to an authorization server and receives an access token. When acting as an authorization server, Datapower accepts and verifies an OAuth request and generates an access token. When acting as an enforcement point for a resource server, Datapower verifies the access token and validates it against the resource the client is requesting. Below steps describes this implementation,
STEP 1 Create an OAuth client object as below,
STEP 2 Create an OAuth client group object as below,
STEP 3 Create a AAA Policy with OAuth Config,
3 A. Extract Identity (EI)
3 B. Authentication (AU)
3 C. Resource Extraction(ER)
3 D. Authorization (AZ)
Sample AAA file,
STEP 4 Create an authorization server using the Web Token Service as below,
4 A.WTS Config,
4 B.WTS generated Processing Policy,
STEP 5 Create a resource server enforcement point using the Multi-Protocol Gateway as below,
5 A. Front Side Handler Config,
5 B. Processing policy for enforcement,
5 C. choose a static backend type, here it is a simple loopback XML Firewall. Request type as non-xml, Response type as Pass through and propagate URI to on.
STEP 6 Testing the Configuration,
6 A. Client request to invoke the authorization service and fetch access token (Web token service)
Curl command,
curl -k https://<dp:ip>:5040/ –user password-client:passw0rd -d “grant_type=password&username=john&password=passW&scope=/getAccount {“token_type”:”bearer”,”access_token”:”bearer”,”expires_in”:3600 }”
6 B. Access token verified by the MPGW (Resource Service)
Curl command,
curl -k https://<dp:ip>:5041/getAccount -H “Authorization: Bearer AAEPcGFzc3dvcmQtY2xpZW50tOItBbbumS0yrr/H+fPT8VbAvrI3xX55MSfy7Pnjz07usWpDnPm+0evCFTcPjtUwt5SrAhdplb3QnH+Dy36pCg”
2.Implementation (Two legged Flow) through WTS (Grant Type Scenario-Client Credential)
In this scenario client itself the resource owner, which means client can get an access token by presenting its own credentials, avoiding its credentials from being exposed in each and every resource request.However,client credentials flow implementation is similar to resource owner password credentials configuration,
STEP 1 Configure the OAuth client application with the Datapower,
1 A.Configure an OAuth Client Profile similar to above implementation except for the grant type as below,
1 B. Configure the created client profile with OAuth Client Group,
1 C. Use the OAuth client group in AAA policy to implement in Authorization service,
Authentication(AU)
Resource Extraction(ER)
Authorization (AZ)
1 D. Use the OAuth client group in another AAA policy(below Config) to implement in Enforcement service,
Resource Extraction(ER)
Authorization(AZ)
STEP 2 Create an authorization service using the Web Token Service,
Create a WTS with SSL proxy profile and get the processing policy generated with AAA action that has OAuth Client configured earlier,
STEP 3 Create a resource server enforcement point using the Multi-Protocol Gateway,
3 A. Create a front side handler that listens the WTS Authorization service,
3 B. Create a processing policy for the enforcement point having the,
3 C. Choose a static backend type, here it is a simple loopback XML Firewall. Request type as non-xml, Response type as Pass through and propagate URI to on.
Troubleshooting the Configurations,
Scenario 1: Scope not sufficient
Request to invoke WTS Authorization service and get access token,
Curl Command,
curl -k https://<dp:ip>:5050/token -u ac-appln:passw0rd -d “grant_type=client_credentials&scope=getAccount”
Response,
Request with access token to enforcement service to get the response,
Curl Command,
curl -k https://<dp:ip>:5051/getAccount -H “Authorization: Bearer AAEIYWMtYXBwbG5NYwZ3Pi01cM3Rge0qjdvfh4VJ19KCNQoEfkbyiiXvCw9oZLfPdwC7OarGlixMcD46KqjChfuuHB6U/vpL7lWp”
Response,
We get the response as insufficient_scope because URL sent by client is checked for the ER phase for the endpoint server AAA policy, here the scope in the token request includes the leading slash.
Scenario 2: Invalid Client Application
Curl Command,
curl -k https://<dp:ip>:5050/token -d “grant_type=client_credentials&scope=/getAccount&client_id=application&client_secret=passw0rd”
Response,
Scenario 3: Success
Curl Command,
curl -k https://<dp:ip>:5050/token -u ac-appln:passw0rd -d “grant_type=client_credentials&scope=getAccount”
Request to invoke enforcement service(MPG),
curl -k https://<dp:ip>:5051/getAccount -H “Authorization: Bearer AAEIYWMtYXBwbG5NYwZ3Pi01cM3Rge0qjdvfh4VJ19KCNQoEfkbyiiXvCw9oZLfPdwC7OarGlixMcD46KqjChfuuHB6U/vpL7lWp“
Response,
Great work, very well simplified the tutorials on IBM website, just noticed the AU step need to be specified in the Client Credential part as Pass Identity Token to the Authorize Step.