Tip:
Highlight text to annotate it
X
[ MUSIC ]
WONG: Welcome to the IBM Security Identity and Access Management Demos Series.
In this recording, we will be focusing on demonstrating risk-based access
and authentication governance on mobile devices to provide a high level of confidence
for transactions using IBM Security products.
In this recording, we will first begin by setting the scene and give context
on the use case, explain the business requirements which this scenario was built upon.
Secondly, we will present to you a recorded demonstration
to showcase using the risk-based access capability offered in IBM Security products
to provide fine-grained authorization decisions and achieve high level of confidence
for a requested transaction on mobile devices.
Thirdly, provide you a summary of what technology is used under the covers;
and finally, show you where you can go to find more information about these products
to build the solution for your enterprise.
The purpose of this business scenario is
to showcase how risk-based access capability can provide access decision and enforcement
for device consent purposes and confidence level for a transaction or purchases.
Another primary focus is to showcase the use of OAuth mobile access and authorization
with OAuth access tokens when performing transaction-based risk-based access
on mobile devices.
The demonstration will showcase purchasing the car insurance package via the mobile device.
We will be basing this demonstration using the IBM Identity
and Access Management sandbox VMware.
This sandbox has been built around a fictional business enterprise called JK Enterprise,
short for JKE, where JKE is a large IBM customer that owns and uses a wide variety
of Identity and Access Management products.
It is assumed at JK Enterprises there is a newly registered customer called Eric Smith,
as per highlighted in the red box in the show and slide.
Eric has just gone through the signup process
and has become a new customer at JK Enterprise Internet site.
In the demo, we will be authenticating
into JK Enterprises using Eric Smith's JK Enterprise Internet account.
Customers are able to make purchases of the JKE car insurance
by a Web browser or via a mobile applications.
The mobile app and mobile device we will be using
for the scenario is through an Android emulator.
This demo will focus on using the mobile app to make purchases.
To use the mobile app on a trusted form to make these purchases,
it is necessary to register the mobile application instance
against the JKE customer account.
This will be Part One of the demo.
Next, once we have the phone and mobile app registered and trusted,
customers can then make car insurance package purchases.
A XACML policy is configured to govern the JK car insurance purchasing workflow and resulting
to different step-up mechanisms to complete the transaction based
on the chosen insurance amount request to purchase.
Customers are able to purchase the car insurance at three different sum amounts,
including $1,000, $12,000 and $20,000.
A transaction is governed by a XACML policy based
on the conditions presented in the table shown.
For JKE car insurance purchases of value $1,000, the transaction is automatically permitted.
For JKE car insurance purchases of values greater than $1,000 but less than or equal
to $12,000, if the mobile app is PIN protected, the transaction is approved.
Otherwise, if the mobile app is not PIN protected, OTP step-up is necessary.
For JKE car insurance purchases of value greater than $12,000, OTP step-up is mandatory.
This will be Part Two of the demo where we will showcase this in the process.
JK Enterprises also has a requirement where with the trusted
and registered mobile application instance against the JKE customer account,
JK Enterprises allows their customers
to self-manage their devices in case it gets stolen or lost.
Customers may disable any registered instance
against their account whereby disabling access prevents unauthorized access
and usage of stolen or lost devices.
As Part Three of the demo, we will show how it is possible
by utilizing the underlying IBM Security products to disable a registered mobile instance
to avoid others from making car insurance purchases on their phone.
Let us now move on to the live demo for this use case.
Part One, registering a mobile instance against a JKE customer account.
Let us consider Eric Smith as a newly registered customer at JK Enterprises.
He just activated his account but has yet to log into his new account.
Let us log in as Eric Smith into the JK Enterprise Internet site.
Upon a successful login, Eric reaches the JKE Internet homepage
where he can see various insurance package deals on promotion.
We will now proceed to the Manage Profile page for Eric's JKE account.
When trying to access his Manage Profile page,
Eric is prompted with a device register consent form.
What this is, is it's asking Eric to register the browser he is currently using
to access his JKE profile as a trusted device.
We will choose to ignore this browser registration consent
by skipping this registration form as it is not related to this demonstration.
Momentarily, we reached the JKE Manage Profile page for Eric's Smith's account.
On this page, we can see his registered personal details and other options to carry
out the profile management operations.
On Eric's profile page, there is an HMAC one-time password shared key.
For the purpose of this demo, it is necessary to scan this password code into a smartphone.
This one-time password is a step-up mechanism to complete purchase transactions
of a large insurance amount as described earlier in the scenario overview.
As a preparation step for this demo, Eric's HMAC one-time password has been scanned using the
Google Authenticator app installed on an Android smartphone as shown on the screen.
We will now return to Eric's Internet account at JK Enterprises and take a look
at what mobile applications and devices have been registered against his account.
As we can see, Eric has not registered any trusted application or device
against his JKE Internet account; hence, the table displayed is empty.
At this stage, we have Eric's JK Enterprise Internet account ready
and have scanned the HMAC one-time password from his profile.
Eric now wants to use his mobile device to make JKE car insurance purchases.
Notice that for this demo we are using an Android mobile emulator
to mimic Eric's mobile device.
Eric has downloaded the JK Enterprise purchase app.
This is a newly installed app on the mobile emulator, which you can see on the screen.
He needs to register it as a trusted device against his JKE profile
so that he can make secure insurance purchases.
When Eric proceeds to register the mobile app, he is asked to provide an authorization code.
This authorization code can only be obtained when Eric has initiated the process
of granting access to register the mobile application via his JK Enterprise
customer account.
With the JK Enterprises mobile application instance, instead of using authorization codes,
it also offers the option to use Eric's username and password
to register the application instance.
However, for the purpose of this demonstration, we are primarily interested
in using the authorization code during an OAuth workflow.
Let us now return to Eric Smith's JK Enterprise account.
We will now proceed to register the JK Enterprise mobile application instance
that we saw on the mobile emulator as a trusted instance against Eric's account.
To register any application or device against his JKE Internet account,
Eric can do so by selecting the manage registrations option under his profile page.
To initiate the registration process,
he selects the register new mobile application on the presented form.
We are immediately displayed with the form requesting for grant access to register the app.
To register the application, an instance name must be specified.
A suggested application instance friendly name is provided and prefilled in the form as shown.
This name may be changed based on personal preference; however,
we would choose to keep this name for the demo.
The registration form also provides the option for a user
to protect the application with a PIN.
For security reasons and the purpose of this demo, we will select the checkbox
to protect the application with a PIN and provide a four-digit number as the PIN.
Upon approval, a registration code is provided.
This is the authorization code that is needed to complete the registration
for the mobile app on the mobile emulator.
Let us return back to the mobile emulator to complete the application registration process.
What you will see on the screen is us manually entering the provided authorization code
into the emulator.
Once the authorization code is submitted and validated to be correct,
you will see that the mobile app says the device is registered with the friendly device name
that was entered during the earlier steps in the mobile application registration process.
Now that we have the mobile app registered, it is now possible to launch the app.
To launch the JK Enterprise application, we need to enter the four-digit PIN,
where this four-digit PIN was the PIN we registered during the mobile application
registration process shown earlier in the demo.
Upon submitting the four-digit PIN, it takes a few minutes for the app to load up.
At this point, the JK Enterprise mobile application is launched successfully
on Eric's device.
Through this app, Eric is able to make car insurance purchases with some assured amounts
and level of [coverage] available.
At this point, let us return to Eric's JK Enterprise profile, and we will take a look
at the information under the managed applications and devices section.
As shown, the registered devices
and applications information has changed for Eric Smith.
We can see the mobile application, which we registered in earlier steps of the demo,
is now listed in the presented table under Eric's account.
We can further click on the name of the registered mobile instance and get presented
with device attribute information specific to this device.
As Part One of the demo, we demonstrated Eric Smith registering the JKE insurance purchase
application instance.
This is a hybrid mobile application that will allow him
to make JKE insurance policy purchases.
Before the mobile application could be used,
Eric needed to register the application instance against his JKE user profile.
Eric needed to register the app via his JK Enterprise Manage Profile page.
Upon registering the device in the mobile emulator, an authorization process
of the app was embodied by the OAuth authorization code flow.
The mobile app supports two options for registration using OAuth tokens:
the first one was OAuth authorization code flow
and OAuth resource owner username and password code flow.
The OAuth authorization code flow was the option that was demonstrated.
It required Eric to enter a mobile application registration code to register the instance.
This authorization code was generated
when Eric initiated the register a mobile application process through his JKE profile.
With the generated authorization code, it was submitted into the mobile application instance.
Once the code was submitted and successfully validated, the instance became registered
against Eric's JKE Internet account as a trusted mobile app for making JKE insurance purchases.
This completed the OAuth authorization code workflow for the scenario.
By employing the OAuth authorization code flow,
there was no password credential exposure to the mobile device.
Next what we saw was Eric would go and launch the mobile app.
Upon launching the app, it allowed him to enter a PIN which he registered
when approving the register of the app in his profile.
By entering the PIN to launch the mobile app, this established a Access Management session.
By registering the mobile device and starting up the app, an OAuth token exchange
with the Access Manager WebSEAL component session cookie occurred.
Part Two, purchasing JKE car insurance via the mobile app.
Following from Part One of the demo,
Eric now has his device trusted and the mobile app registered.
He may now proceed to purchase JKE car insurance via the mobile app.
To do this, let us first launch the JK Enterprise app in the mobile emulator.
Once the mobile app is launched successfully, it will present to us with the form within the app
that will list the different sell amounts and levels
of coverage available for car insurance purchasing.
To begin with, let us consider that Eric wants to purchase the car insurance policy
with a sum amount of $1,000 for his first car.
He will select the amount in the app and click buy now.
Immediately, he will be informed that the purchase has been successful.
Now let us assume that Eric decides he wants to purchase a car insurance policy
for a second car he owns with a sum amount of $15,000.
He goes ahead and selects the amount in the app and clicks buy now.
Immediately he'll be informed that the insurance purchase has been successful.
Assume moments down the track Eric decides that he wants
to purchase car insurance for a third car.
He wants to purchase the car insurance policy with the sum amount of $20,000.
Following similar steps as before, he selects $20,000
as the amount in the app and clicks buy now.
This time Eric is prompt in the app that he needs to step up in order to proceed
with the payment for such a large amount.
He is asked to choose a one-time password delivery method to step up.
Eric chooses the time-based HMAC one-time password method.
Here, he will be using the one-time password secret which was scanned
on his Android smartphone, which we showed very early on in the demo.
Once he selects that option, Eric is asked to use that one-time HMAC secret
from his smartphone to provide the one-time password.
What we are showing in the screen here is Eric returning to his Android smartphone
to obtain the current time-based HMAC one-time password, and then entering it
into the mobile app within the provided text field.
Once the one-time password has been submitted and validated to be correct,
he is immediately notified that the transaction for $20,000 is successful.
During Part Two of the demo, we saw Eric making purchases of the JKE car insurance policies
through the JK Enterprise mobile app.
Within the JK Enterprise mobile app, Eric was able to initiate request
to purchase the JKE car insurance at different values.
Behind the scenes, transaction was governed by an XACML policy based
on the different sum amount values offered for purchase by JKE.
We saw when Eric was purchasing $1,000
for the insurance the transaction was automatically permitted.
When he then went to purchase $12,000, although we saw that it was permitted automatically,
in fact, behind the scenes a policy was checking the sum amount to be greater
than $1,000 but less or equal to $12,000.
Furthermore, because the mobile app was protected
by a PIN, the transaction was approved.
Next, in the case where Eric was purchasing an insurance policy with a sum amount of $20,000,
the time-based HMAC one-time password which was scanned from Eric's Manage Profile page,
was used at accept step-up for the transaction.
One of the main aspects to takeaway from Part Two of the demo is
that the transactions were fully driven and governed by a risk-based access XACML policy.
The rules in the policy included one-time password as an obligation.
Part three, managing aspects of mobile access for trusted devices.
Let us consider the case if Eric were to lose his mobile device.
He would want to disable or unregister the mobile app to avoid others
from making car insurance purchases on his phone.
It is possible to manage aspects of Eric's mobile access
where we can disable the registered device against his JK Enterprise customer account.
So, what we will do is go to JKE Internet site and log in as Eric Smith.
We will proceed to the Manage Profile page of his account when he has logged in.
We will ignore and skip the device registration form in the browser.
Under his Manage Profile page, we will go to the mobile applications
and devices section of his profile.
From there, we will be presented with a table listing all registered devices
against Eric's account.
In that table, we will see the browser device is registered as well as the mobile device.
We will proceed to disable the mobile device under his account.
Once Eric has submitted the request to disable the mobile device under his profile,
this information is immediately updated where you can see the status of the mobile device
in the table is updated to be disabled.
We will now return to the mobile emulator and attempt
to make a car insurance purchase in the mobile app.
Let us attempt to relaunch the mobile app as we did before.
When we have submitted the PIN to attempt to launch the app, we see the app is attempting
to establish a new user session and upload the device's fingerprint.
Within moments, it informs us that it is unable to launch the app because the exchange
of an access token for the session has failed.
Let us return to the JK Internet site
to re-enable the device against Eric's user account.
With the device re-enabled now, we will now return back
to the mobile emulator to set up the app again.
This time, as you can see, the mobile app was launched successfully.
In Part Three of the demo, by disabling the registered mobile application,
we have temporarily disabled the OAuth registration
for the JKE insurance mobile application.
When Eric attempted to launch the app, behind the scenes it attempts
to establish a user session and upload the device's fingerprint.
It also tries to refresh the OAuth token but fails.
This is because this stage of the OAuth token has been disabled
and Federated Identity Manager is denying validation of the access and refresh token.
When we re-enable the app against Eric's profile, the application can be relaunched.
Notice if the token was completely removed from Eric's mobile application list,
it would require him to reregister the device.
Under the covers, the products that are used
to achieve this result include IBM's Security Access Manager where it is providing
that point-of-contact for Web application access
and enforcing the context authorization using Federated Identity Manager;
there is also IBM Tivoli Federated Identity Manager.
All through this demo it is showcasing a number of different features.
Firstly, it is showcasing the risk-based access capability in the demo.
The risk-based access feature provides access, decision,
and enforcement for device consent purposes and confidence level
of a transaction for the car insurance purchases.
The second feature is one-time password capability
where we saw the one-time password workflows used in step-up transactions made
on the registered trusted mobile app during purchase transactions for the JKE car insurance.
And thirdly is the OAuth capability
where Federated Identity Manager was following OAuth standards and token access
when performing transaction-based risk-based access on the mobile device.
As we saw in the demo, we used this feature during the registering of the device
in the mobile emulator where an authorization process of the app was embodied
by the OAuth authorization code flow.
We also saw a later part of the demo during the disabling of the mobile app
where behind the scenes we were temporarily disabling the OAuth registration
of the JK insurance mobile app; and, hence,
Federated Identity Manager was denying the validation of the access and refresh tokens.
All product features discussed and highlighted through this demo, they have been configured
to provide you an experience of the capabilities that it may provide and support your enterprise.
Each of the features can be further deployed and configured to address a wider variety
of business scenarios to provide a high level of confidence
for the transaction or extend use case workflows.
To find out more about the product offerings,
go to the IBM Security software products Web site shown on this slide.
You can find information about each of the products highlighted in this demonstration.
It will also provide you contact details on how to contact IBM
to help you build a solution for your business needs.