1.6.1 Online Web Application
This topic describes about the online web application.
Authentication and authorization to requests to access the Online Web Application(appshell) are controlled using the below industry standard approaches:
- Standard LDAP Directory authentication
- SSO with OAM
- SSO with other External SSO Agents
- SAML with the Oracle Banking Microservices Architecture application acting as the service provider
- SAML SSO Integration
JWT (JSON Web Tokens)
In addition to the authentication, the Oracle Banking Microservices Architecture online web application uses JWT to maintain the state for authenticated users.
JSON Web Tokens are an open and industry-standard RFC 7519 method that
secures the claims securely between two parties. JWT is a compact and URL-safe for
transferring claims between two parties. The claims in JWT are encoded as a JSON
object, which is used as the payload of the JWS or as plain text of the JWE
structure, allowing claims to be digitally signed.
- No Session to Manage (stateless): The JWT is a self-contained token which has authentication information, expire time information, and other user defined claims digitally signed.
- Portable: A single token can be used with multiple backends.
- No cookies required, it is mobile friendly.
- Good Performance: It reduces the network round trip time.
- Decoupled/Decentralized: The token can be generated anywhere. Authentication can happen on the resource server or easily separated into its own server.
The policies for JWT are as follows:
- Token Store: To increase security and better usability, every authentication/refresh request is secured by a random unique key. The generated token and the secure key are persisted in the table, so that during the horizontal scaling of the servers, any API gateway instance can serve for the request.
- Cipher strength: The Platform security module hashes the JWT footer with HS512 algorithm.
- Refresh Token: The users are allowed to get the new token any time before expiring the existing token.
- Claims: The JWT Claims Set represents a JSON object whose members are the claims conveyed by the JWT. Platform security module validates the below claims during the process.
Table 1-2 JWT Claims set
| Claim Name | Description | Mandatory | Type |
|---|---|---|---|
| iss | Issuer | Yes | Registered |
| sub | Subject | Yes | Registered |
| aud | Audience | No | Registered |
| exp | Expiration Time | Yes | Registered |
| nbf | Not Before | No | Registered |
| jat | Issued At | Yes | Registered |
| jti | JWT Id | Yes | Registered |
| tid | Tenant Id | Yes | Private |
- Token Expiry: The platform security module invalidates the token if the client submits after the expiration time.
- Logout: While user calls the logout operation, platform security module clears the issued token and deletes the record from the table as well. The old token will no longer be used for any purpose.
The various security flows for the online web application are depicted below.
LDAP Authentication
- The user is presented the standard login page for the Oracle Banking Microservices Architecture application.
- The user enters the User ID and Password. The credentials are validated against a standard LDAP store.
- If successful, the API Gateway generates a JWT token (Utilizing Oracle’s Security Developer Toolkit part of Oracle’s Platform Security Services), persists it in the Database and returns the same
OAM Based SSO
- The online UI is protected on OAM.
- Client requests protected resource. OAM presents SSO login screen.
- Client enters User Id and Password. In case of success, OAM sets the corresponding user profile details in the security context.
- The request is sent to plato-apigateway-router and request will be routed to the Gateway.
- The API Gateway creates a JWT token (Using Oracle Security Developer Toolkit part of Oracle Platform Security Services), maintains it in the Database and returns the same.
- The UI layer uses this token to maintain state and conduct subsequent invocations.
Product configuration
The following parameters need to be set to enable a successful integration with OAM as SSO in Oracle Banking Microservices Architecture products
PLATO.SECURITY_CONFIG table
USER_HEADER_ATTRIBUTE_KEY,IS_SSO_CONFIGURED USER_MAPPING_REQUIRED to be set as
true.
| ID | KEY | VALUE |
|---|---|---|
| 1 | USER_HEADER_ATTRIBUTE_KEY | userId |
| 2 | USER_HEADER_ATTRIBUTE_REQUIRED | Y |
| 3 | IS_SSO_CONFIGURED | true |
| 4 | USER_MAPPING_REQUIRED | true |
Figure 1-3 PLATO.SECURITY_SMS_USER_MAPPING table
SAML Authentication
IDP Initiated SAML Authentication
Figure 1-4 IDP Initiated SAML Authentication
- The Identity Provider is external to the Oracle Banking Microservices Architecture application with the Oracle Banking Microservices Architecture application acting as the Service Provider. For example, OKTA.
- Client requests protected resource from Oracle Banking Microservices Architecture. The Idp presents a configured login screen to the user.
- Client enters a user id and password. In case of success, the Idp sets the corresponding user profile details in the security context.
- The request is sent to plato-apigateway-router and request will be routed to the Gateway.
- The API Gateway creates a JWT token (Utilizing Oracle’s Security Developer Toolkit part of Oracle’s Platform Security Services), persists it in the Database and returns the same.
- Configure an external service to do the SAML Verification in API Gateway with EXTERNAL_SSO_VALIDATION_URL parameter in the SECURITY_CONFIG table in PLATO-SECURITY schema.
- The implementation team needs to develop an external service to validate the SAML token.
SP Initiated SAML Authentication
Figure 1-5 SP Initiated SAML Authentication
- The user initiates a call to the Oracle Banking Microservices Architecture application and is redirected to the federate login page of the bank.
- Oracle Banking Microservices Architecture does not have any code for the IDP Redirection. This has to be completely customized by the implementation team where a new service file has to be built and to be deployed which can perform the redirection.
- The Identity Provider is external to the Oracle Banking Microservices Architecture (e.g. OKTA) with the Oracle Banking Microservices Architecture products acting as the Service Provider.
- The Idp presents a configured login screen to the user.
- Client enters a user id and password. In case of success, the Idp sets the corresponding user profile details in the security context.
- The request is sent to plato-apigateway-router and request will be routed to the Gateway.
- The API Gateway creates a JWT token (Utilizing Oracle’s Security Developer Toolkit part of Oracle’s Platform Security Services), persists it in the Database and returns the same.
- Configure an external service to do the SAML Verification in API Gateway with EXTERNAL_SSO_VALIDATION_URL parameter in the SECURITY_CONFIG table in PLATO-SECURITY schema.
- The implementation team needs to develop an external service to validate the SAML token.
SAML SSO Implementation
Steps to achieve SSO-SAML Authentication:
- Bank user will try to access the Oracle Banking Microservices Architecture app-shell URL.
- Oracle Banking Microservices Architecture will check if the IS_SSO_CONFIGURED parameter is set to true in the SECURITY_CONFIG table.
- If the IS_SSO_CONFIGURED parameter is true the user will be redirected to the IDP for authentication.
- Oracle Banking Microservices Architecture does not have any code for the IDP Redirection. This has to be completely customized by the implementation team where a new service file has to be built and to be deployed which can perform the redirection.
- On successful authentication IDP will generate the SAML token and pass the token to the Oracle Banking Microservices Architecture assertion consumer service URL in the body of POST method through EXTERNAL_SSO_KEY parameter.
- Oracle Banking Microservices Architecture will receive the token and check if the SSO_SERVICE_PROVIDER is set to EXTERNAL in the SECURITY_CONFIG table.
- If SSO_SERVICE_PROVIDER is EXTERNAL, Oracle Banking Microservices Architecture would make a HTTP Post call to SVS using the EXTERNAL_SSO_VALIDATION_URL configured in the SECURITY_CONFIG table for SAML token validation. Oracle Banking Microservices Architecture will pass the SAML token through EXTERNAL_SSO_TOKEN_KEY parameter in the body of the POST to SVS.
- The implementation team needs to develop an external service to validate the SAML token.
- SVS will return a response with Status as success and, Oracle Banking Microservices Architecture would generate JWT token using the user id from the SVS response and allow the user to login.
- In case of failure, Oracle Banking Microservices Architecture would give login error to the user.
Product Configurations required:
The following parameters needs to be configured in the
SECURITY_CONFIG table in the PLATO-SECURITY schema to enable SAML SSO.
| KEY | VALUE |
|---|---|
| IS_SSO_CONFIGURED | True |
| JWT_EXP_SECONDS | JWT expiry time |
| JWT_ALGORITHM | HS512 |
| EXTERNAL_SSO_VALIDATION_URL | SVS URL |
| EXTERNAL_SSO_KEY | Parameter in which the SAML token will be passed to Oracle Banking Microservices Architecture from IDP after user authentication. |
| SSO_SERVICE_PROVIDER | EXTERNAL |
| EXTERNAL_SSO_TOKEN_KEY | Parameter in which the SAML token will be passed to SVS URL for token validation. |
| HEADERS | Request headers for making HTTP call to SVS URL |
FCUBS integration with Oracle Banking Microservices
Architecture as SSO Provider
Refer to Launching Oracle Banking Microservices Architecture from UBS section in the Oracle Banking Microservices Architecture Installation Guide.