OAuth 2.0 Example for AS Java

The following example describes how a Web application can be protected via OAuth 2.0 for SAP NetWeaver AS Java.

Company A is developing a Web application for create, read, update and delete (CRUD) operations. The owner of the application is the CRUDAdmin user, which means that the CRUD application can be accessed with this user. Donna Moore, as an OAuth administrator of the company, proceeds as follows in order to protect the application via OAuth:

Donna creates the following two UME roles that she will protect the application with:
1. ReadRole
  
  This role allows the CRUD application to perform a read operation. For ReadRole Donna also assigns an readAction action, which contains ReadPermission permission.
2. WriteRole
  
  This role allows the CRUD application to perform a create, update, and delete operations. In addition, Donna assigns an writeAction action, which contains CreatePermission, UpdatePermission, and DeletePermission permissions.
Donna protects the application with the ReadRole and WriteRole roles by using either the programmatic authorization approach or the declarative (container-based) one. For more details, see Declarative and Programmatic Authorization.
For the web application to be accessed via OAuth 2.0, Donna includes OAuth2LoginModule in the login module stack of the application.

She does this by adding the following configuration in the application's web-j2ee-engine.xml file:
```
<login-module-configuration>
  <login-module-stack>
   <login-module>
    <login-module-name>com.sap.security.oauth2.login.OAuth2LoginModule</login-module-name>
    <flag>SUFFICIENT</flag>
   </login-module>
  </login-module-stack>
 </login-module-configuration>
```
For more information, see Editing the web-j2ee-engine.xml.
Donna assigns the ReadRole and WriteRole roles to the CRUDAdmin user since this user is the owner of the application and must have administration rights for it.

Now the CRUDAdmin user has full access to the resource and can perform all of the CRUD operations.
Donna assigns a scope to the read role.

Donna wants the CRUDAdmin user to be able to grant the right to an OAuth 2.0 client for performing the read operation of the user's application. To allow this, there has to be a scope assigned to the ReadRole role. She therefore assigns a scope with READ value to the ReadRole role. The assigned READ scope is actually a dynamic authorizations scope, and it has to be mapped to a corresponding OAuth 2.0 scope. For more information on how to assign scopes, see Dynamic Authorizations.

Note

In OAuth 2.0, a scope represents a specific permission for accessing a resource. In SAP NetWeaver AS for Java, the equivalent of an OAuth 2.0 scope is the UME role, which represents a set of permissions granted to the users which are assigned to the role. As a consequence of this, in OAuth 2.0 for AS Java, the OAuth 2.0 scopes are represented through UME roles. For the mapping between a scope and a role, the UME dynamic authorization mechanism is used.
Donna Moore, as an OAuth 2.0 administrator, accesses the OAuth 2.0 administration UI and creates a client named ReadClient.
Donna Moore registers a scope with READ ID for the ReadClent.

This scope exactly matches the value of the scope assigned to the ReadRole role for dynamic authorizations.

As a result, the ReadClient client should be able to request read access for the CRUD application from the CRUDAdmin user.

Once Donna has configured the OAuth authorization, she informs the users of the registered ReadClent that they can use the CRUD application for read operations. Consequently, when a third-party vendor uses the ReadClent client, the process flow is as follows:

The ReadClient client makes an authorization grant request for the READ scope in order to obtain read access for the CRUDAdmin's resource, which is the CRUD application.
The CRUDAdmin user grants the READ scope to the client, who then receives an authorization code.
The client connects with the authorization server and exchanges the authorization code for access and refresh tokens (confidential clients must use the HTTP Basic authentication scheme as described in HTTP Authentication: Basic and Digest Access Authentication when making requests for an access token).

The ReadClient client can use the access token to access the CRUD application with read access rights and can use the refresh token to get another access token from the authorization server.
The ReadClient client makes an OAuth 2.0 request for accessing the CRUD application with read access rights.

This is done by setting the obtained access token as bearer token in the Authorization header of the request, as described in The OAuth 2.0 Authorization Framework: Bearer Token Usage.
The ReadClient client is authenticated as CRUDAdmin on the server.

The client is granted only the ReadRole role, which allows the ReadClient client to perform read operations only in the CRUD application.