Configure a Protected Resource

This guide explains how to configure a protected resource on the RSA, which involves protecting and managing resources such as Active Directory user details at the LDAP provider. When users attempt to connect at the Wallet, they are redirected to the RSA-LDAP Adapter login page where they must authenticate themselves using their LDAP credentials. Using these credentials, the RSA executes an LDAP search query for the user's details/Active Directory listing. The context that will be set at LDAP server for this query is based on the user credentials provided, ensuring that only relevant user details may be searched and requested. Once LDAP verifies the credentials and identifies the user details accordingly within the LDAP tree, these details will be sent as a response to the query made by the RSA. These details are the "resource" that the RSA protects.

Protecting a Resource

The value assigned to the fpx.oidc.provider.userinfo_endpoint field within the config file will be the endpoint from which this protected resource will be retrieved. The RSA can automatically protect and share any resources that were retrieved from an LDAP instance (after successful user authentication) from this endpoint. A configuration enabling the userinfo endpoint at the RSA-LDAP to be protected and to allow resources (LDAP user details) to be shared from this endpoint is shown below within the sample configuration file.

For this, some static configuration details must be provided (Zuul).

Zuul Configuration

If configured correctly, the Zuul configuration enables requests at the RSA to be re-routed to its own userinfo endpoint (as opposed to forwarding to a true resource server/3rd party provider) from which user details/data can be retrieved. Pre-configured routes must be supplied to allow this dynamic re-routing. The example below essentially enables all requests arriving at "https://{rsa-url}/api/ to be routed off to https://{rsa-url}/ 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-base-url}/api/xyz" is made at the RSA, it would be forwarded to "https://{rsa-url}/xyz.

As mentioned above, real LDAP user data/details will be stored at the RSA and may only be requested at the RSA's protected userinfo endpoint. If `fpx.oidc.provider.userinfo_endpoint has been configured as '/userinfo' and the resource request (by the Service Provider) is made to /api/userinfo path of the RSA (i.e. https://{rsa-url}/api/userinfo), the gateway capability of the RSA (Zuul) will ensure that all requests will be forwarded to the aforementioned userinfo endpoint of the RSA (after the request has been checked for proper authorization and access), which would be "https://{rsa-url}/userinfo".

zuul:
  debug:
    request: true
  routes:
    userinfo:
      path: /api/**
      url: forward:/
      sensitiveHeaders: Cookie,Set-Cookie
      stripPrefix: true

Database Configuration

The following entries need to be made in the database used by the RSA. First, an entry must be made to the protected_http_path table. This entry will represent the path at which the SP will use to request the resource with the Access token granted by the Authorization Server mentioned above.

INSERT INTO protected_http_path (id, version, date_created, last_updated, path, auth_server) 
VALUES (1, 1, now(), now(), "/api/{path-to-be-appended-at-real-api}"}, 2);

Note how the path begins with "/api" which corresponds to the prefix supplied in the Zuul config above (zuul.routes.userinfo.path). The Authorization Server reference must correspond to the id in the oauth_provider table that represents the Authorization Server.

Next, an entry must be made to the resource table which represents a resource registered at a given Authorization Server.

INSERT INTO resource (id, version,date_created, last_updated, name, resource_id, type, auth_server)
VALUES (1, 1, now(), now(), "example-resource", "example-resource-id", "{url-desrcribing-active-directory-details}", 2);

The 'resource-name' can be a generic user-friendly name however the 'resource_id' above MUST be the SAME as it is in the Authorization Server DB. The 'identifier' field within the rs_resource (for the corresponding resource entry at the Wallet) table AT THE WALLET must also have the same value as the value set here for 'resource_id'. The type above should be a URL that leads to a webpage describing what the active directory resource is and what it should look like. The Authorization Server reference must correspond to the id in the oauth_provider table that represents the Authorization Server.

Next, an entry must be made to the protected_resource_path_mapping table. This entry outlines links a protected_path to a resource registered at a given Authorization Server.

INSERT INTO protected_resource_path_mapping (id,version, date_created, last_updated, method, path_id, resource_id) 
VALUES (1, 1, now(), now(), "GET", 1, 1);

The path_id and resource_id must correspond to the id of the appropriate entry within the protected_http_path and resource tables respectively.

Lastly, an entry must be made to the protected_resource_path_mapping_scopes table. This entry would represent the scopes the Service Provider is required to have been granted access to by the RQP, in order to access a protected path of the RSA.

INSERT INTO protected_resource_path_mapping_scopes (path_mapping, scope) 
VALUES (1, "example-scope");

A path can have multiple scopes granted to it. The path_mapping above must correspond to the id at the protected_resource_path_mapping table.

Styling Configuration Items

Default location for the styling of the Consent page (The Login page where the user inputs their LDAP credentials) resides within the RSA-LDAP project itself.

If the default option is acceptable, insert the following config field consent-view.css into the configuration file and use the hardcoded value of the RSA's base URL + "/style.css" as the value of this field.

consent-view.css: http://{rsa-url}/style.css

To override, simply replace the URL with the address of your preferred customized CSS stylesheet.