Implementation of LDAP
LDAP is a protocol through which Directory Service is connected. In Directory Service, the user’s information is stored in a hierarchical structure.
The following properties are added in the $OPE_HOME/roles/authorization-service/standalone/config/application.properties file to configure Directory Service:
- directoryServiceDomainName=test
- directoryServiceRootDistinguishedName=DC=testad,DC=com
- ldapURLForDirectoryService=ldap://localhost:389
Authentication and Authorization
In TIBCO Offer and Price Engine, support for authentication and authorization of all the available microservices is added. Authentication is used to authenticate someone's identity, whereas authorization is a way to permit someone to access a particular resource.
Authentication Factors
Based on the security levels and the type of security that the application requires, there are different types of authentication factors. TIBCO OPE supports Single-Factor authentication. This authentication mechanism requires users to provide a user name and password to access the system.
Authorization Technique
The role-based access control technique is used to give users access to the TIBCO Offer and Price Engine resources.
Authorization Service
Authorization Service is a microservice available as part of TIBCO Offer and Price Engine 6.0.0 This microservice has the following key features:
- This service generates JWT tokens based on OAuth2 specifications.
- Grant_Type used is
password
- User credentials are entered in the request body when generating the OAuth2 token.
This service accepts encrypted passwords.
Once a user generates the token, it has to be entered as part of the header in each request (SOAP or REST). This token is used to verify the user's identity and authority.
Resource Server
As per OAuth2 specification, a resource server is a server that hosts the protected resources and can accept and respond to protected resource requests by using access tokens.
Each TIBCO OPE microservice is embedded with a resource-server library with the following capabilities:
- Verify token validity by using the same signing that was used to sign the token when it was generated by Authorization Service.
- Check token expiry.
- Extract claims from the token and set TenantId and authorities for the user.
- As part of the microservices configuration in TIBCO OPE, each API exposed for the user has been protected with configurable role restrictions.
Generating User Token
The following methods describe the steps to generate a token if the user's information is stored with Authorization Service, in an external directory, or using a third-party external service:
Information stored with Authorization Service
Customers can choose to store TIBCO OPE user information in the Admin data store created and managed by TIBCO OPE.
The user credentials are encrypted and stored in the backing datastore.
The following sequence diagram illustrates token generation when the user’s information is available in the Admin datastore:
Information stored in External Directory
Customers can choose to use the preexisting Directory Service(DS) which stores all the user information rather than replicating it in the Admin datastore.
Authorization Service can communicate with any external DS over LDAP or secured LDAP. Here, Directory Service acts as an IdP. The following sequence diagram illustrates token generation when the user’s information is available in an external Directory Service:
Using a third-party external service
Customers might have an existing token generation mechanism (or service) and they might prefer using it for TIBCO OPE 6.0.0
The Resource-Server library embedded in every microservice of TIBCO OPE expects OAuth2 JWT token must have a payload containing the following information:
user_name
TENANTID
- an array of authorities containing roles of the user for whom this token was generated and these roles must have been configured for the API.
- The token must be signed with the secret string configured as a value of property
authentication.token.signing.key
If the token follows all the above rules, then all the microservices in TIBCO OPE accept the token even if it is generated from a third-party service.
Sample Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX25hbWUiOiJhZG1pbiIsIlRFTkFOV ElEIjoiVElCQ08iLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiZXhwIjoxNjQ2MDc0MjY3L CJhdXRob3JpdGllcyI6WyJST0xFX0FETUlOIl0sImp0aSI6IjViZDlhZmExLTJjZGEtNDZjO S05NGJjLTU0NmVkNjlhNjc4ZiIsImNsaWVudF9pZCI6Im9yZGVyLW1hbmFnZW1lbnQtY 2xpZW50In0.tkbrHuFBvBo8N7Tshp4uXLxhjaYjBfWCoPccpCJtlxU
When you read the token, it displays the following payload.
{ "header": { "alg": "HS256", "typ": "JWT" }, "payload": { "user_name": "admin", "TENANTID": "TIBCO", "scope": [ "read", "write" ], "exp": 1646074267, "authorities": [ "ROLE_ADMIN" ], "jti": "5bd9afa1-2cda-46c9-94bc- 546ed69a678f", "client_id": "order-management-client" } }