Chapter 9. OAuth2-Based Security for OData

9.1. OAuth2-Based Security for OData

In this example you will learn how to secure Red Hat JBoss Data Virtualization’s OData REST interface with OAuth2 using Red Hat SSO as the identity provider. It is also possible to delegate the negotiated OAuth2 access token at the OData interface, to the underlying data sources used in the Virtual Database, if the data source is also secured through Red Hat SSO as identity provider.

9.1.1. Configuring Your Red Hat SSO Server

Prerequisites

You must have Red Hat SSO installed as a separate web server, preferably on a different server machine.

  1. Go to http://localhost:8080/auth/admin/master/console/#/realms/oauth and use the default admin/admin credentials. (You may have to create a Red Hat SSO administrative account in order to do this.)
  2. Under the General tab, add a new realm called oauth-demo.
  3. Under Manage -> Users, click Add User and add a new user called user with credentials.
  4. Under Configure - Roles - Realm, click Add Roles and add the odata and user roles to your new user.
  5. Under Configure - Clients - Settings, add a new client called odata4-oauth. Add the odata and user roles and then choose scopes odata and user for this client.

    Note

    The redirect URI needs to be where the actual service is going to be available. Here is an example: http://[host]:[port]/odata4/*
    The client web-service defines the roles the logged-in user must have in order to be granted access. In the Red Hat SSO OAuth2 implementation, these roles are used as scopes. Note that the odata4-oauth client must have the scopes that it is going to delegate the access-token for gaining access to bottom data services. In this example Red Hat JBoss Data Virtualization’s OData web services requires the odata role. If you are delegating the access-token to the underlying web-service requires the user role.

    Note

    The user role is suggested as an example role required for the underlying source webservice. You need to replace it with the real role required for the webservice.

9.1.2. Configure the Red Hat JBoss Data Virtualization server

Prerequisites

Red Hat JBoss Data Virtualization server installed.

Red Hat SSO Adapter for EAP installed in Red Hat JBoss Data Virtualization.
  1. Follow the instructions found here in the Red Hat SSO documentation to install the EAP 6 adapter: https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/paged/securing-applications-and-services-guide/chapter-2-openid-connect
  2. Run this script to change the OData transport’s security-domain section: 
    ./bin/jboss-cli.sh --connect
/subsystem=teiid/transport=odata:write-attribute(name=authentication-security-domain, value=keycloak)

reload
    The code will change to look like this: 
        <transport name="odata">
        <authentication security-domain="keycloak"/>
    </transport>
    Note that, for this to deploy, you must also have the security domain configured on the server. To do so, run these commands to create Oauth and Keycloak security domains: 
    /subsystem=security/security-domain=oauth:add(cache-type=default)
/subsystem=security/security-domain=oauth/authentication=classic:add
/subsystem=security/security-domain=oauth/authentication=classic/login-module=oauth:add(code=org.teiid.jboss.PassthroughIdentityLoginModule, flag=required, module=org.jboss.teiid)
 
/subsystem=security/security-domain=keycloak:add(cache-type=default)
/subsystem=security/security-domain=keycloak/authentication=classic:add
/subsystem=security/security-domain=keycloak/authentication=classic/login-module=keycloak:add(code=org.keycloak.adapters.jboss.KeycloakLoginModule, flag=required)
 
reload
  3. Undeploy the WAR file: 
    undeploy teiid-olingo-odata4.war
  4. Download the Maven project found here: https://github.com/teiid/teiid-web-security
  5. Replace the teiid-web-security/teiid-odata-oauth-keycloak/src/main/webapp/WEB-INF/keyclock.json file’s contents with the installation script from the Red Hat SSO admin console’s odata4-client application.
  6. Edit the teiid-web-security/odata-oauth-keycloak/src/main/webapp/WEB-INF/web.xml file to enable passthrough authentication: 
    <init-param>
        <param-name>PassthroughAuthentication</param-name>
        <param-value>true</param-value>
    </init-param>
  7. Use Maven to build the WAR file.
  8. Deploy the WAR file using this script: 
    deploy PATH/teiid-olingo-odata4.war
  9. Go here to test: http://localhost:8180/odata4/keycloak/auth

Note

Testing only: The token will expire after a time, meaning that you will need to negotiate for a new one. To do so, go to http://localhost:8180/odata4/keycloak/auth.

Note

If you are writing browser-based applications which will use this virtual database as a service to access data, these applications need mechanisms to negotiate access tokens from RH-SSO directly. The method discussed above is provided for testing purposes only.
You can also invoke this service programmatically. This process does not need to involve a web-browser and is typical of the situation whereby another web-application or mobile application is calling Red Hat JBoss Data Virtualization’s OData web-service to retrieve the data. The process of negotiating the access-token is externalized and is defined by the identity provider which, in this case, is Red Hat SSO.
To demonstrate, CURL is used below to negotiate this token (client_secret can found the Keycloak admin console under client credentials tab): 
curl -v POST http://localhost:8080/auth/realms/oauth-demo/protocol/openid-connect/token -H Content-Type: application/x-www-form-urlencoded -d 'username=user' -d 'password=user' -d 'grant_type=password' -d 'client_id=odata4-oauth' -d 'client_secret=36fdc2b9-d2d3-48df-8eea-99c0e729f525'
A JSON payload is returned: 
    {  "access_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0YjI4NDMzYS1.."
,
       "expires_in":300,
       "refresh_expires_in":1800,
       "refresh_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmY2JmNjY2ZC0xNzIwLTQwODQtOTBiMi0wMjg4ODdhNDkyZWYiLCJl..",
       "token_type":"bearer",
       "id_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIwZjYyNDQ1MS1iNTE0LTQ5YjUtODZlNy1jNTI5MDU2OTI3ZDIiLCJleH..",
       "not-before-policy":0,
       "session-state":"6c8884e8-c5aa-4f7a-a3fe-9a7f6c32658c"
    }
Now take the access_token and issue a query like this to access the OData service: 
     curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0YjI4NDMzYS1.." http://localhost:8180/odata4/oauthdemo/view/message
You will see the same response message returned that you saw using the browser above.

9.1.3. Delegation of an OAuth2 Token to a Data Source

In order to delegate the same OAuth2 access token negotiated at the OData layer, you need to use RH-SSO as your identity provider in developing this web service. There are few additional steps you need to take to enable Red Hat SSO as the identity provider for this service:
  1. Log into the RH-SSO admin console.
  2. Under the realm oauth-demo, and then Clients -> Settings, add another client called database-service and set the scope to user. Set the type to Bearer.
  3. Follow the instructions in RH-SSO to secure this web service with above realm oauth-demo
  4. Deploy this WAR into your web server.
  5. Create a web service resource adapter for this service, using oauth as the security-domain.
  6. Use this resource adapter as source in developing your virtual database.

    Note

    The delegation will occur if the virtual database is accessed through the OData interface. JDBC-based access to this virtual database would fail.