Skip to main content

Configure a Protected Resource

Overview and Application Config

The RSA's purpose is to protect and manage resources (an API/endpoint at the federated OIDC provider). The RSA can automatically protect and share any resources that the user's access token at the Federated OIDC Providers is valid for. The simplest example would be the 'userinfo' endpoint (https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse). A configuration allowing the 'userinfo' endpoint at the Federated OIDC Providers to be protected and shared through UMA is shown below.

For this we must provide some static and database configuration details.

Zuul Configuration

The Zuul configuration enables requests at the RSA to be re-routed to appropriate endpoints at a given protected Resource Server (The Federated OIDC Provider). Pre-configured routes must be supplied to allow dynamic re-routing. The example below essentially states that all requests arriving at "https://{{RSA_URI}}/api/ must be routed off to https://{example-hosted-api-host-and-path}/ where the wild card "**" is the only part of the initial request that's carried over and appended to the protected Resource Server's URL (corresponds to "zuul.routes.url" below). For example, if a request "https://{{RSA_URI}}/api/userinfo" is made at the AS, it would be re-routed to "https://{example-hosted-api-host-and-path}/userinfo.

zuul:
debug:
request: true
routes:
userinfo:
path: /api/**
url: https://{example-hosted-api-host-and-path}
sensitiveHeaders: Cookie,Set-Cookie
stripPrefix: true
NOTE

Notice in the sample configuration provided here how the federated_issuer (within the OIDC provider config) and the URL supplied within Zuul configuration are not the exact same. The federated_issuer value is the OIDC issuer value of the federated provider whereas the url supplied in the zuul configuration is the part of the path where the access token (generated by the Federated Provider and received by the RSA) is to be used to get the resource for the service provider.

Sensitive Headers

You can share headers between RSA and the Federated Provider. However, you may not want sensitive headers leaking downstream into the Federated Provider. By default, Zuul will send all headers to the proxied path. Depending on your Federated Provider's security policy/deployment configuration (ingress controller settings, etc.), proxy headers (sent as part of a Zuul forwarded request) may lead to unexpected results. 401 errors can occur even if the request made to the Federated Provider is accompanied with an appropriate and valid access token. You can specify a list of ignored headers as part of the route configuration using zuul.routes.{route-name}.sensitiveHeaders.

Consider adding 'x-forwarded-host' to zuul.routes.{route-name}.sensitiveHeaders and re-deploy the RSA if such errors occur. The sensitive headers can be configured as a comma-separated list per route, as shown in the above snippet.

For more information and fine-grained control of the Zuul Proxy mechanism in Spring Boot, refer to https://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html and modify the Zuul configuration snippet within the RSA yaml configuration accordingly.

Sample Requests using Admin API

This section details the requests needed to configure a protected resource at the RSA. This configuration must be accompanied by requests made to the Wallet and Authorization Server as well. The links below lead to more information on doing this for each component.