OpenLDAP for authentication and RBAC of management services

Contents

Overview
Step 1: create an OpenLDAP group for RBAC roles
Step 2: add RBAC roles to the OpenLDAP RBAC group
Step 3: add users to the OpenLDAP RBAC group
Step 4: create an LDAP connection
Step 5: create an OpenLDAP repository
Step 6: create a test policy for LDAP authentication and RBAC
Step 7: use the OpenLDAP policy to protect management services

Overview

This topic explains how to use Local Directory Access Protocol (LDAP) to authenticate and perform Role-Based Access Control (RBAC) of management services. You can use the sample Protect Management and Interfaces (LDAP) policy instead of the Protect Management Interfaces policy. This means that an LDAP repository is used instead of the local Admin User store for authentication and RBAC of users attempting to access the management services. This topic describes how to reconfigure the server to use OpenLDAP as the LDAP repository, and to use the Apache Directory Studio as an LDAP browser.

[Note] Note

This topic applies to both API Gateway and API Gateway Analytics.

Prerequisites

This example assumes that you already have configured connection to the OpenLDAP server and setup your organization groups and users that you wish to use to perform RBAC. For example:

  • LDAP URL: ldap://openldap.qa.oracle.com:389

  • User: cn=admin,o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE

  • Password: oracle

Step 1: create an OpenLDAP group for RBAC roles

To create a new user group in OpenLDAP, perform the following steps:

  1. Select the cn=admin,o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE directory.

  2. Right-click, and select New > New Entry.

  3. Select Create entry from scratch.

  4. Click Next.

  5. Add an organizationalUnit object class.

  6. Click Next.

  7. Set the Parent to o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE.

  8. Set the RDN to ou = RBAC.

  9. Click Next.

  10. Click Finish.

Creating an OpenLDAP Group

You can view the new group using an LDAP Browser. For example:

Viewing an Active Directory LDAP Group

Step 2: add RBAC roles to the OpenLDAP RBAC group

You must add the following default RBAC roles to the ou=RBAC,o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE group to give the LDAP users appropriate access to the API Gateway management services:

  • API Gateway Administrator

  • API Gateway Operator

  • KPS Administrator

  • Policy Developer

  • Deployer

These RBAC roles are located in the roles section of the acl.json file.

Adding Roles to the RBAC Directory

To add these RBAC roles to the OpenLDAP RBAC group, perform the following steps:

  1. Select the cn=admin,o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE directory.

  2. Right-click, and select New > New Entry.

  3. Select Create entry from scratch.

  4. Click Next.

  5. Add a groupOfNames object class.

  6. Click Next.

  7. Set the Parent to ou=RBAC,o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE.

  8. Set the RDN to cn = Policy Developer.

  9. Click Next.

  10. In the DN Editor dialog, set admin as first member of the following group: cn=admin,ou=R&D,o=Vordel Ltd.,l=Dublin 4,st=Dublin,c=IE. You can change the member Distinguished Name at any time.

  11. Click OK.

  12. Click Finish.

Adding the Role to the OpenLDAP Group

You can view the role in the OpenLDAP group in an LDAP Browser. For example:

Viewing the Role in the OpenLDAP Group

Add other roles to the RBAC directory

You can repeat these steps to add other roles to the RBAC directory. Alternatively, you can copy the Policy Developer entry, and paste it into the RBAC directory, renaming the entry with required RBAC role name. For example:

Copying Roles to RBAC Directory

[Note] Note

You should have the RBAC directory ready to add members to the role entries. By default, the admin user (“cn=admin,ou=R&D,o=Vordel Ltd.,l=Dublin 4,st=Dublin,c=IE”) is already a member of the role entries.

The following example shows the added roles:

Viewing Copied Roles

Now you can add new users to the RBAC role entries. The member attribute value should contain the user Distinguished Name. This is explained in the next section.

Step 3: add users to the OpenLDAP RBAC group

To add a user to the OpenLDAP RBAC group, perform the following steps:

  1. Select the required RBAC group (for example, cn=API Gateway Administrator) to view the group details.

  2. Right-click the list of group attributes, and select New Attribute.

  3. Enter member in the attribute type.

    Adding the Role to the OpenLDAP Group

  4. Click Finish.

  5. In the DN Editor dialog, enter the user Distinguished Name (for example, cn=joe.bloggs,o=Vordel Ltd.,l=Dublin 4,st=Dublin,c=IE).

  6. Click OK.

The cn=joe.bloggs,o=Vordel Ltd.,l=Dublin 4,st=Dublin,c=IE new user has been added to the RBAC API Gateway Administrator role.

Step 4: create an LDAP connection

To create an new LDAP Connection, perform the following steps:

  1. In the Policy Studio, select Open File , and select the Admin Node Manager configuration file (for example, INSTALL_DIR\apigateway\conf\fed\configs.xml).

  2. In the Policy Studio tree, select External Connections > LDAP Connections.

  3. Right-click, and select Create an LDAP Connection.

  4. Complete the fields in the dialog as appropriate. For example:

    Creating an LDAP Connection

    [Note] Note

    The specified User Name should be an LDAP administrator that has access to search the full directory for users.

  5. Click Test Connection to ensure the connection details are correct.

Step 5: create an OpenLDAP repository

To create an new OpenLDAP Repository, perform the following steps:

  1. In the Policy Studio tree, select External Connections > Authentication Repository Profiles > LDAP Repositories.

  2. Right-click, and select Add a new Repository.

  3. Complete the following fields in the dialog:

    Repository Name Enter an appropriate name for the repository.
    LDAP Directory Use the LDAP directory created in the section called “Step 4: create an LDAP connection”.
    Base Criteria Enter the LDAP node that contains the users (for example, see the LDAP Browser screen in the section called “Step 3: add users to the OpenLDAP RBAC group”).
    User Search Attribute Enter cn. This is the username entered at login time (in this case, admin).
    Authorization Attribute Enter cn. The authentication.subject.id message attribute is set to the value of this LDAP attribute (for example, cn=admin,ou=R&D,o=Vordel Ltd.,l=Dublin 4,st=Dublin,c=IE. The authentication.subject.id is used as the base criteria in the filter used to load the LDAP groups (the user’s roles). This allows you to narrow the search to a particular user node in the LDAP tree. For more details, see the Retrieve Attributes from Directory Server filter in the section called “Step 6: create a test policy for LDAP authentication and RBAC”.


    Creating an LDAP Repository

Connect to other LDAP repositories

This topic uses OpenLDAP as an example LDAP repository. Other LDAP repositories such as Oracle Directory Server (formerly iPlanet and Sun Directory Server) and Microsoft Active Directory are also supported. For details on using a Microsoft Active Directory repository, see Active Directory for authentication and RBAC of management services. For an example of querying an Oracle Directory Server repository, see the Retrieve Attributes from Directory Server filter in the section called “Step 5: create a test policy for LDAP authentication and RBAC”.

Step 6: create a test policy for LDAP authentication and RBAC

To avoid locking yourself out of the Policy Studio, you can create a test policy for LDAP authentication and RBAC, which is invoked when a test URI is called on the server (and not a management services URI). For an example policy, select Policies > Management Services > Sample LDAP Policies > Protect Management Interfaces (LDAP) when the Admin Node Manager configuration is loaded.

Create the test policy

Perform the following steps:

  1. Select Open File and load the Admin Node Manager configuration file in the Policy Studio. For example: 

    INSTALL_DIR/apigateway/conf/fed/configs.xml

  2. Right-click the Policies node in the tree view of the Policy Studio, and select Add Policy .

  3. Enter a suitable name (for example Test Policy) for the new policy in the Name field, and click the OK button. The new policy is now visible in the tree view.

  4. Click the new policy in the tree view to start configuring the filters for the policy. You can easily configure the policy by dragging the required filters from the filter palette on the right of the Policy Studio, and dropping them on to the policy canvas.

For more details on creating policies, see the API Gateway User Guide.

Configure the test policy

Configure the test policy with the following filters:

Configure a Test Policy for LDAP and RBAC

Scripting Language filter

This includes the following settings:

Scripting Language Filter

The Scripting Language filter performs the following tasks:

  1. Returns true if the Node Manager is the Admin Node Manager, and passes control to the HTTP Basic Authentication filter.

  2. Otherwise, calls the Call Internal Service (no RBAC) filter without adding the authentication.subject.role and authentication.subject.id HTTP headers.

Call Internal Service (no RBAC) filter

This filter is called without adding any HTTP headers as follows:

Call Internal Service (no RBAC) Filter

HTTP Basic Authentication filter

This filter uses the LDAP repository configured in the section called “Step 5: create an OpenLDAP repository”, and includes the following settings:

HTTP Basic Authentication Filter

The HTTP Basic Authentication filter performs the following tasks:

  1. Connects to the LDAP directory using the connection details specified in the LDAP directory.

  2. Finds the user using the specified base criteria and search filter.

  3. If the user is found, verifies the user's name and password against the LDAP repository by performing a bind.

  4. If authentication fails, always throws a 401. This allows retry for browser users.

  5. The distinguishedName (DName) is held in the authentication.subject.id message attribute. This is specified by the Authorization Attribute field in the LDAP repository configuration.

  6. The user’s roles (LDAP groups) are not available yet.

Retrieve Attributes from Directory Server filter

On the Database tab, this filter uses the LDAP directory configured in the section called “Step 4: create an LDAP connection”, and includes the following settings:

  • Retrieve Unique User Identity From Selector Expression:

    ${authentication.subject.id}

  • Base Criteria:

    ou=RBAC,o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE

  • Search Filter:

    (&(objectclass=groupOfNames)(member=CN=${authentication.subject.id},ou=R&D,o=Vordel Ltd.,l=Dublin 4,st=Dublin,C=IE))

  • Attribute Name:

    cn

Retrieve Attributes from Active Directory Server

[Note] Note

On the Advanced tab, you must ensure that the Enable legacy attribute naming for retrieved attributes setting is selected.

The Retrieve Attributes from Directory Server filter performs the following tasks:

  1. Using the user’s DName as the search start point, finds the user’s cn attribute, and loads the LDAP groups for the user.

  2. If the user is in one group, the group name is contained in the user.cn message attribute.

  3. If the user is in multiple (n) LDAP groups, the group names are contained in user.cn.1 ... user.cn.n message attributes.

Management Services RBAC filter

This filter includes a the following setting:

Management Services RBAC Filter

The Management Services RBAC filter performs the following tasks:

  1. Reads the roles from the user.cn.* message attribute. It understands the meaning of the wildcard, and loads the roles as required. It creates a string version of the roles, and places it in the authentication.subject.role message attribute for consumption by the Call Internal Service filter, which receives the roles as an HTTP header value.

  2. Determines which Management Service URI is currently being invoked.

  3. Returns true if one of the roles has access to the Management Service currently being invoked, as defined in the acl.json file.

  4. Otherwise, returns false and calls the Return HTTP Error 403: Access Denied (Forbidden) policy. The message content of this filter is shown when a valid user has logged into the browser, but their role(s) does not give them access to the URI they have invoked. For example, this occurs if a new user is created and they have not yet been assigned any roles.

Call Internal Service filter

This filter includes a the following settings:

Call Internal Service Filter

The Call Internal Service filter sends the message to the internal service with the following additional HTTP headers:

  • authentication.subject.role

  • authentication.subject.role

[Note] Note

The authentication.subject.id message attribute is specified using ${authentication.subject.orig.id} because authentication.subject.id holds the full DName, and the cn only needs to be passed to the services.

Test the policy configuration

To test this policy configuration, perform the following steps:

  1. In the Policy Studio tree, select Listeners > Node Manager > Add HTTP Services, and enter a service name (for example, LDAP Test).

  2. Right-click the HTTP service, and select Add Interface > HTTP.

  3. Enter an available port to test the created policy (for example, 8888), and click OK.

  4. Right-click the HTTP service, and select Add Relative Path.

  5. Enter a relative path (for example, /test).

  6. Set the Path Specify Policy to the Protect Management Interfaces (LDAP) policy, and click OK.

  7. Close the connection to the Admin Node Manager file and reboot the Admin Node Manager so it loads the updated configuration.

  8. Use API Gateway Explorer to call http://localhost:8080/test.

  9. Enter the HTTP Basic credentials (for example, username admin and password Oracle123). If authentication is passed, the Admin Node Manager should return an HTTP 404 code (not found).

Step 7: use the OpenLDAP policy to protect management services

If the authentication and RBAC filters pass, you can now use this policy to protect the management interfaces. To ensure that you do not lock yourself out of the server, perform the following steps:

  1. Make a copy of the conf/fed directory contents from the server installation, and put it into a directory accessible from the Policy Studio.

  2. Make another backup copy of the conf/fed directory, which will remain unmodified.

  3. In the Policy Studio, select File > Open, and browse to configs.xml in the first copy of the fed directory.

  4. Under the Listeners > Management Services node, select the / and the /configuration/deployments relative paths, and set the Path Specify Policy to the Protect Management Interfaces (LDAP) policy.

  5. Remove the previously created LDAP Test HTTP Services.

  6. Close the connection to the file.

  7. Copy the fed directory back to the Admin Node Manager’s conf directory.

  8. Reboot the Admin Node Manager.

  9. Start the Policy Studio, and connect to the Admin Node Manager using admin with its LDAP password (for example, Oracle123). You should now be able to edit API Gateway configurations as usual.

Prev  Up  Next
  Home