Online Web Application

JWT (JSON Web Tokens)

In addition to the authentication, Oracle Banking Virtual Account Management 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 between two parties. JWT is compact and URL-safe for transferring claims between two parties. The claims in JWT are encoded as the JSON object, which is used as the payload of the JWS structure 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 backend.
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 the security and better usability, every authentication/refresh request is secured by 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 below claims during the process.

Table 1-2 Claims

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
iat	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 Online Web Application are as follows,

OAM based SSO
LDAP Authentication
SAML Authentication

LDAP Authentication

Figure 1-1 LDAP Authentication

Description of "Figure 1-1 LDAP Authentication"

The user is presented the standard login page for the Oracle Banking Virtual Account Management application.
The user enters user ID and password. The credentials are validated against a standard LDAP store.
If successful, the API Gateway generates a JWT token (using Oracle Security Developer Toolkit part of Oracle Platform Security Services), maintains it in the Database and returns the same.

OAM Based SSO

Figure 1-2 OAM Based SSO

Description of "Figure 1-2 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 routed to the Gateway which extracts the profile details from the security context.
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 o 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

Description of "Figure 1-3 PLATO.SECURITY_SMS_USER_MAPPING table "

SAML Authentication

IDP Initiated SAML Authentication

Figure 1-4 IDP Initiated SAML Authentication

Description of "Figure 1-4 IDP Initiated SAML Authentication"

The Identity Provider is external to the Oracle Banking Virtual Account Management application with the Oracle Banking Virtual Account Management application acting as the Service Provider. For example, OKTA.
Client requests protected resource from Oracle Banking Virtual Account Management. 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 routed to the Gateway which extracts the profile details by decoding the SAML response.
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.
It is possible to configure an external service to do the SAML Verification instead of the API Gateway using the EXTERNAL_SSO_VALIDATION_URL parameter in the SECURITY_CONFIG table in PLATO-SECURITY schema

SP Initiated SAML Authentication

Figure 1-5 SP Initiated SAML Authentication

Description of "Figure 1-5 SP Initiated SAML Authentication"

The user initiates a call to the Oracle Banking Virtual Account Management application and is redirected to the federate login page of the bank.
The Identity Provider is external to the Oracle Banking Virtual Account Management products (e.g. OKTA) with the Oracle Banking Virtual Account Management 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 routed to the Gateway which extracts the profile details by decoding the SAML response
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.

SAML SSO Implementation

It is possible to configure an external service to do the SAML Verification instead of the API Gateway.

Figure 1-6 SAML SSO Implementation

Description of "Figure 1-6 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 Virtual Account Management 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.
On successful authentication IDP will generate the SAML token and pass the token to the Oracle Banking Virtual Account Management assertion consumer service URL in the body of POST method through EXTERNAL_SSO_KEY parameter.
Oracle Banking Virtual Account Management 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 Virtual Account Management 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 Virtual Account Management will pass the SAML token through EXTERNAL_SSO_TOKEN_KEY parameter in the body of the POST to SVS.
SVS will return a XML response with IsValid tag as TRUE or FALSE. If the tag value is TRUE, Oracle Banking Microservices Architecture would generate JWT token using the user id from the <subject> </subject> tag of SVS response and allow the user to login.
In case of failure, Oracle Banking Virtual Account Management 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 Virtual Account Management 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 Virtual Account Management from UBS section in the Oracle Banking Virtual Account Management Installation Guide.