Trying Out CIBA POC of WSO2 IS

Episode 04 — Demonstration with Architecture Approach V1.0

Vivekvinushanth Christopher
Authenticate
5 min readOct 9, 2019

--

Fig.1. Demo [https://www.vectorstock.com/royalty-free-vector/demo-sign-icon-demonstration-symbol-vector-13504460 ]

User Story

Last week my friend Alice went to a mall. He purchased many goods but at the counter, he realised that he missed his purse on the way or left it at home. He doesn't have any means of paying; No credit cards, cash and even reluctant to buy on a credit. But he managed to pay 15K LKR. How was it possible?

Let’s see in detail what had happened?

Video.1. One kind of User Story where CIBA is instrumental.

How was that actually possible?

Of course,

  1. ‘Payhere’ app
  2. CIBA powered by WSO2-IS

What is CIBA ?

Client-Initiated Back-Channel Authentication of OpenID Connect which is a new specification to address the necessity where client apps [of Consumption device] initiating the authentication request for the end-user of its own interest. And end-user will have to authenticate from the authentication device which is physically decoupled.

Please do read these blogs for a better understanding of the specification “CIBA”.

Summarizing the specification and the blogs that read above,

CIBA is :

  1. Client-Initiated Authentication Requests which are backchannel and hence without any browser redirections

Though CIBA spec is especially meant for Client initiating Authentication requests for the user of their own interest [without user acting upon the consumption evice], CIBA doesn't bother if the consumption device obtain the user identity from the user and initiate a request since user-triggered them

2. Since CIBA is meant for Client App in Consumption devices initiating the request and expects the user at the Authentication device to authenticate himself, eventually consumption device is physically decoupled from authentication device. Hence CIBA embraces “Decoupled Authentication”.

3. CIBA enforces polling. The Authorization server[Identity provider] has to manage load due to polling.

What is the Approach towards Architecture [atleast for POC] ?

We choose Proxy Approach especially because,

  1. To withstand the load by polling
  2. Have minimized changes on IS, at least at POC period.

Do read about our approach [V1.0] from this following blog

Can We have a demo?

Why Not !!

Video.2. Demonstration of CIBA POC of WSO2 -IS

Can we try it ourselves?

Of course Yes.

Follow the steps below to try out CIBA POC for WSO2-IS

  1. Download WSO2-IS[5.8.0] from here
  2. Follow the installation guide to run IS
  3. Add and Configure a Service Provider in WSO2-IS

a. Set the callback URL as http://localhost:8080/CallBackEndpoint [Must]

This Callback URL takes you to the CallBack EndPoint of the Proxy, so that proxy can capture and update the auhentication status of the request that was made by the Proxy to WSO2-IS. And port 8080 is what CIBA-Proxy-Server uses.

b. Copy the client-ID and client-Secret from the configuration of Service provider

Fig.2. Configured Service Provider — WSO2-IS

4. Download Ciba Authenticator.jar from here

Or you can find the repo from here and build it again and follow the documentation to add custom authenticators

5. Download Patched EmailOTP from here and add it to the following folder replacing the existing EmailOTP Authenticators

6. Create new Identity provider and set federated authenticator as the email OTP

Fig.3. Configured Identity Provider — WSO2-IS

7. Follow the documentation to set up email OTP as multifactor authentication and Configure the authentication steps as below

Fig.4. Configuring MultiStep Authentication— WSO2-IS

8. Create a new user at IS [specify a correct email]

Fig.5. Add a new user — WSO2-IS

9. In the CIBA-Proxy-Extension that you have opened in an IDE, go to

a. update the clientID and clientSecret with the value copied from step 4.b.

b. Update the StoreConnectorType

It can be either of those JDBC or InMemoryCache

c. Set the preferred username, password and database name of the databse[supports only MySQL] if the StoreConnectorType is JDBC

d. Set the FlowMode

It can be either of those: POLL or PING

e. Build CIBA-Proxy-Extension and run

10. Get DemoApp from here [it is a locally hosted website]

11. Start the flow.

a. Choose PayHere

Fig.6. PayHere Home page— PayHere App

b. Input your username[of the user you created]

Fig.7. PayHere user identity input page — PayHere App

c. You can see the auth_response received and pending for authentication

Fig.8. PayHere pending authentication— PayHere App

d. Go to email[use the same browser-because all are locally hosted] from a browser from your laptop. You can see an email OTP as a URL.

Fig.9. EmailOTP— Email

e. Click the URL and provide the consent.

Fig.10. Consent Page — WSO2-IS

f. Go to your demo app page and check whether you received the tokens[transaction successful mesage]

Fig.11. PayHere Transaction Successful -PayHere App

Note: You can check both perspectives of the user and the developer in the split-screen. You are Welcome !!.

Glitches :

1. There is a glitch when user has denied the access.Will be rectified in the following updates for the POC.

2. There is another glitch — ‘HTTP client not found-404’ when Proxy server [it works as a rest client when it communicates to WSO2-IS] is communicating with /authorize end point.It doesn’t affect the flow, but has to be handled.

Pardon me.

Where Can we found your ‘CIBA’ and related artefacts?

--

--