Online Web Application

1.4.1 Online Web Application

The Online Web Application can be secured through the industry standards and policies.

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 Branch products application acting as the service provider

In addition to the authentication, the Oracle Banking Branch products online web application uses JSON Web Tokens (JWT) to maintain the state for authenticated users.

JWTs are an open, industry-standard RFC 7519 method for representing claims securely between two parties. JWT is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed.

Table 1-3 Features

Feature	Description
No Session to Manage (stateless)	The JWT is a self-contained token that 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 very 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 be easily separated into its own server.

In addition, the following policies are followed for JWT:

Table 1-4 Policies

Policy	Description
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	Platform security module hashes the JWT footer with the HS512 algorithm.
Refresh Token	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. The platform security module validates the claims mentioned in the Table 1-5 during the process.
Token Expiry	Platform security module invalidates the token if the client submits after the Expiration Time.
Logout	While the user calls the logout operation, the platform security module clears the issued token and deletes the record from the table as well. The old token no longer will be used for any purpose.

Table 1-5 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

The various security flows for the online web application are depicted below:

LDAP Authentication

The flow is depicted below:

Figure 1-1 LDAP Authentication

Description of "Figure 1-1 LDAP Authentication"

The security flow is as follows:

The user has presented the standard login page for the Oracle Banking Branch products.
The user enters a 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 flow is depicted below:

Figure 1-2 OAM Based SSO

Description of "Figure 1-2 OAM Based SSO"

The security flow is as follows:

The online UI is protected on OAM.
The client requests protected resource. OAM presents the SSO login screen.
Client enters a 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 (Utilizing Oracle’s Security Developer Toolkit part of Oracle’s Platform Security Services), persists in the Database, and returns the same.
The UI layer uses this token to maintain the 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 Branch 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

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

SAML Authentication

The flow is depicted below:

Figure 1-4 IDP Initiated SAML Authentication

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

The security flow is as follows:

The Identity Provider (IdP) is external to the Oracle Banking Branch Application (For example, OKTA) with the Oracle Banking Branch application acting as the Service Provider.
Client requests protected resource from Oracle Banking Branch. 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 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 security flow is as follows:

The user initiates a call to the Oracle Banking Branch application and is redirected to the federate login page of the bank.
The Identity Provider is external to the Oracle Banking Branch products (example OKTA) with the Oracle Banking Branch 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 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 are as follows:

Bank user will try to access the Oracle Banking Branch app-shell URL.
Oracle Banking Branch 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 Branch assertion consumer service URL in the body of POST method through EXTERNAL_SSO_KEY parameter.
Oracle Banking Branch 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 Branch 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 Branch will pass the SAML token through EXTERNAL_SSO_TOKEN_KEY parameter in the body of the POST to SVS.
SVS will return an XML response with IsValid tag as TRUE or FALSE. If the tag value is TRUE, Oracle Banking Branch would generate a JWT token using the user id from the <subject> </subject> tag of the SVS response and allow the user to login.
In case of failure, Oracle Banking Branch 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.

Table 1-6 SECURITY_CONFIG

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 Branch as SSO Provider

Refer to Launching Oracle Banking Branch from UBS section in the Installation Guide.

Parent topic: Securing Oracle Banking Branch Product