Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

Chapter 10. OAuth2-Based Security for OData

10.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

10.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. Please consult the Red Hat SSO documentation for more information about this.

  1. Log into the Dashboard at http://localhost:8080/auth/admin/master/console/#/realms/oauth using 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.
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. Change the OData transport’s "security-domain" section using this CLI script: 
    /subsystem=teiid/transport=odata:write-attribute(name=authentication-security-domain, value=oauth)
    The code will change to look like this: 
        <transport name="odata">
        <authentication security-domain="oauth"/>
    </transport>
    Note that, for this to deploy, you must also have the security domain configured on the server. To do so, run these CLI commands to create oauth and keycloack 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. Run the following CLI to 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" client application.
  6. Run this maven command to build the authentication module: 
    mvn clean package
  7. Deploy the WAR file using this script: 
    deploy PATH/teiid-olingo-odata4.war
  8. To test using a browser, go to this address: http://localhost:8180/odata4/keycloak/auth
  9. Confirm that you can see a message that states "Congratulations!!! Login successful..".
    You can now execute any OData specific URL and that will participate in OAuth2 using OpenID Connect extension in RH-SSO.

Note

Testing only: When this testing is used, the token will expire after a time, meaning that you will need to negotiate for a new one by re-executing 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.

10.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.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部