Channels Technology

Authentication - What’s new

Last updated 28 February 2019
There are a series of new features regarding the authentication process, implemented starting R18:

l User Provisioning: The User Provisioning process updates the Authentication system when an External
User is created in Core Banking. This is achieved through Integration Framework (IF). Events are designed
against the EB.EXTERNAL.USER application and an XML message will be exposed after the External User is cre-
ated. The XML message will be transmitted to the Authentication system either through ESB Adapters or mes-
sage listener APIs, normally occurring outside Core Banking.

l Authentication: The Internet Banking solutions running on default Model Bank support Basic Authentic-
ation, using the T24Authenticator component in the Interaction Framework layer. However, Internet Banking
is enhanced to support the following authentication solutions as out of box:

n Pluggable component: An external authentication provider, without any Core Banking codes /know-
ledge dependencies, can design the pluggable component.

n Temenos owned OIDC authentication: This feature represents the capability of IRIS to authenticate via
OpenID Connect authentication.

Figure: Authentication - What's new in R18

The major changes implemented starting with R18 are related to the following topics:

FEAtures Team Strategy-Dev Page| 1

Channels Technology

User Provisioning

The credentials (user name and password) for the external users are stored, maintained and validated in the
Authentication system. Core Banking does not offer any functionality to store and /or validate passwords of the
External Users.
When logging into Internet Banking, the user’s request is always verified within the Authentication system
before the request is sent to Core Banking.
The Authentication system will be updated with the user name and some additional data from CUSTOMER
table, every time a new Internet Banking User or External User is created in Core Banking.
This process is called User Provisioning and it is achieved through CALLJ integration, a synchronous call with
Authentication system.
The change in R18 related to User Provisioning is that this process is moved out of Core Banking, and the
External User information is exposed through a Temenos Integration Framework (IF) event as XML Message.

Figure: User Provisioning – Back-End Integration with Authentication system through ESB.

There are many Industry standard ESB solutions available on the market, such as Oracle Service Bus (OSB),
Microsoft Biztalk, IBM Integration Bus (IIB), FIORANO and TIBCO.
Banks without ESB need a custom listener program, that can receive the XML message from the Core Banking
Application Server's JMS queue, and send it to Authentication system.

FEAtures Team Strategy-Dev Page| 2

Channels Technology

UXP Authentication

The Internet Banking solutions running on default Model Bank support Basic Authentication, using the
T24Authenticator component in the Interaction Framework layer.
Here are the authentication solutions integrated out of the box for Internet Banking starting R18:

l Temenos owned OIDC authentication : OIDC authentication for web applications and interaction APIs
allows Banks to choose an out-of-the-box, standards based, easy to implement solution from technology
vendors. There are various OpenID Connect authentication providers on the market who may provide these
authentication services. This feature highlights the IRIS capability to authenticate via OpenID Connect. This
Internet Banking OIDC system will redirect the users to perform the authentication within the Authentication
Server’s Login page. After authentication, the Authentication Server will call back the Internet Banking sys-
tem, to load the Internet Banking Homepage screen.

l Pluggable component: Internet Banking R18 provides an easy way of adding/ deploying this component.
The pluggable component can be designed by external authentication providers, without any Core Banking
dependable codes/ knowledge. The external authentication provider’s plug in component must have the cap-
ability of complying with the Open Id Connect specifications. The plug in component must return the JSON
Web Token (JWT) to Internet Banking upon successful user log in. JWT will be passed into Interaction layer, in
order to get the Core Banking details to Internet Banking.

Figure: Authentication – Front-End Integration with Authentication system and IRIS through oAuth2.0.

FEAtures Team Strategy-Dev Page| 3

Channels Technology

Implementation

How are the new features to be delivered?

Changes will be delivered as part of R18 AMR Model Bank, and will have the following features:

No. Feature How it will be delivered

1 User Pro- Integration Events published to Core Banking, which will listen to the application
visioning EB.EXTERNAL.USER.

2 Authentication Internet Banking and Mobile Banking Projects and War files without any authen-
tication solution incorporated. Services Partners or Banks should integrate with the
Authentication components that are published on Marketplace. Authentication can
also be written locally during the implementation, and should to be managed by Bank
or Services.

How are the new features to be enabled?

Here is how the new features are enabled:

No. Feature How it will be enabled

1 User Pro- Integration events are already configured in Core Banking R18. During the creation of
visioning an External User, an IF XML message will be exposed either through the JMS Queue,
or through ESB Adapters. The transformation of the Authentication system has to be
managed out of Core Banking either in ESB or in JMS Listeners.

2 Authentication Internet Banking and Mobile Banking are delivered without any Authentication. The
Authentication components from Marketplace should be incorporated and deployed
during implementations.

Which Core Banking components are involved?

There are no Core Banking components involved in these changes.

Which Core Banking data items are involved?

No. Feature Core Banking data items

1 User Pro- The event definitions are published in IF.EXIT.POINTS>EB.EXTERNAL.USER,

visioning IF.INTEGRATION.FLOW.CATALOG>ExternalUser-ExternalUserFlow.

2 Authentication N/A

FEAtures Team Strategy-Dev Page| 4

Channels Technology

How is the existing database affected by the R18 AMR changes?

No. Feature Database impact

1 User Pro- The event definition records in the table IF.EXIT.POINTS,

visioning IF.INTEGRATION.FLOW.CATALOG are delivered. During creation of a
EB.EXTERNAL.USER record, a corresponding IF.EVENTS.INTERFACE.TABLE record will
be created, with event message and its timestamp values.

2 Authentication N/A

Licensing

There are no new license requirements for activating these changes in R18 AMR.
Dependencies on other modules

No. Feature Modules

1 User Pro- Integration Framework Runtime license (IF) is needed to process the Integration Flow
visioning events.

2 Authentication N/A

Dependencies on Technology

No. Feature Technology 

1 User Pro-
l Design Studio and Event Designer are required, if the integration events are to be
visioning
designed/ modified during implementation.

l ESB Adapter is needed, if ESB will be used.

l II – IBM Integration Bus Adapter.

l BZ – BizTalk Adapter.

l FI – Fiorano ESB Adapter.

l OS – Oracle Service Bus Adapter.

l TI – TIBCO ESB Adapter.

2 Authentication UXP Deployer license is needed, if the authentication integration involves UXP project
changes. However, since the authentication solution on Marketplace is designed to
work as plug and play, it should not require a UXP license.

FEAtures Team Strategy-Dev Page| 5

Channels Technology

APIs

No. Feature APIs

1 User Pro- N/A. Integration Framework (IF) is configured to trigger an event during External User
visioning creation.

2 Authentication N/A

Upgrade procedure for the client

Here's how the client will upgrade to future releases containing these changes:

No. Feature Modules

1 User Pro- Impact in Core Banking is minimal because it is all about configuring the Integration
visioning Framework Event in Design Studio and publishing it to Core Banking. Locally modified
or created IF Event should be maintained by the Bank or Services.

2 Authentication The Internet Banking Product is not delivering any Authentication mechanism. The
Authentication will be managed by Authentication/ Services Partners. The UXP
Authentication components will be maintained by the Bank or the Authentication Part-
ners. Upgrading any components will be managed locally by the Bank or by Authentic-
ation/ Services Partners.

Impact on clients using releases prior to R18

The enhancement was released only in R18, so clients prior to R18 can achieve the new authentication by hav-
ing local configurations.

l Could these changes be implemented for clients that use releases prior to R18?

No. Feature Modules

1 User Pro- Clients with R14 and above can use Design Studio to design the event and publish it to
visioning Core Banking. If required, they can have the Adapters perform the transformation to
Authentication Providers.

2 Authentication Total local development is needed to design the authentication solution as for the R18
AMR Internet Banking solution. For releases prior to R18, Internet Banking is not com-
patible with the OIDC authentication or the pluggable component.

FEAtures Team Strategy-Dev Page| 6

Channels Technology

l How can these changes be implemented?

The Bank can refer to the guideline documents for User Provisioning and UXP Authentication to implement the
solution prior to R18.

l What are the configurations that can be made on spot and what is considered as a code changer?

The entire front-end Internet Banking solution needs to be development locally based on client requirements.
There are no product deliverables for this local development and Services/ L3 teams perform the code changes
according to the Authentication providers chosen by the client.

l Do earlier releases (<R18) support other providers?

Earlier releases support only HID ActivIdentity as an out of the box solution.
If the Bank wants other providers to be supported by the solution, the integration should be made on self-
development or follow the R18 Authentication guidelines for both User Provisioning and UXP Authentication.
This will be considered as a local solution specific to Bank.

FEAtures Team Strategy-Dev Page| 7