Self-service user registration and password reset

If you are following the progress of OpenAM in the nightly builds you'll have seen that there has been a fair bit of effort in the new User Interface or XUI. This is a richer UI that uses the REST APIs exposed by OpenAM and so it also serves as a good example for others looking to build their own apps.

But apart from just looking a lot nicer, XUI uses a few newer REST calls to deliver some useful new functionality too. For example, most help-desk calls revolve around setting up new accounts and forgotten passwords. And when we're talking about internet facing services, as with Identity Relationship Management, this problem rapidly scales up to become a nightmare. So one of the aims of XUI is to support self-service user registration and password reset, reducing costs and increasing customer satisfaction at the same time.

It's easy to try this out for yourself. With a recent nightly build of OpenAM do this:
  1. Configure the REST Security Service globally or per realm:
    • global: Configuration...Global...REST Security.
    • per realm: <realmname>...Services, add the REST Security service. 
    • (Note: the name of this service may change before OpenAM 12 is released ;-) )
  2. Turn on the services you require:



Then when you next hit the Login page you'll see the new self-service options there for you to try:


Both Self-service Registration and Password Reset use mail as part of the process, so remember to setup up your email service in OpenAM (globally in Configuration...Global or per Realm as a Service).

When you click on "Register" the process is then:
  • Supply an email address and you're emailed a link: 
  • Click on the link to complete the registration process
  • et Voilà!
Simple eh?

- FB

Self-service user registration and password reset

If you are following the progress of OpenAM in the nightly builds you'll have seen that there has been a fair bit of effort in the new User Interface or XUI. This is a richer UI that uses the REST APIs exposed by OpenAM and so it also serves as a good example for others looking to build their own apps.

But apart from just looking a lot nicer, XUI uses a few newer REST calls to deliver some useful new functionality too. For example, most help-desk calls revolve around setting up new accounts and forgotten passwords. And when we're talking about internet facing services, as with Identity Relationship Management, this problem rapidly scales up to become a nightmare. So one of the aims of XUI is to support self-service user registration and password reset, reducing costs and increasing customer satisfaction at the same time.

It's easy to try this out for yourself. With a recent nightly build of OpenAM do this:
  1. Configure the REST Security Service globally or per realm:
    • global: Configuration...Global...REST Security.
    • per realm: <realmname>...Services, add the REST Security service. 
    • (Note: the name of this service may change before OpenAM 12 is released ;-) )
  2. Turn on the services you require:



Then when you next hit the Login page you'll see the new self-service options there for you to try:


Both Self-service Registration and Password Reset use mail as part of the process, so remember to setup up your email service in OpenAM (globally in Configuration...Global or per Realm as a Service).

When you click on "Register" the process is then:
  • Supply an email address and you're emailed a link: 
  • Click on the link to complete the registration process
  • et Voilà!
Simple eh?

- FB

Entering via the Administrator’s door

OpenAM's Authentication capabilities are pretty powerful (e.g. previous post), but as Spiderman almost said, "with great power comes great risk", and there is always the danger of locking yourself out. Having done this several times already this week, it's time to write down how to recover...

I was playing with a new OpenAM Authentication Module (more on this in a later blog) and I foolishly included the new module straight into the default authentication chain, so that when I encountered a bug I then couldn't login to correct the problem (or so I thought).

To limit the lockout risk, I guess I should have tested the module (ahead of putting it in the default chain) using one of these approaches:
  1. If the module can be executed standalone (rather than in a chain), explicitly specify the module in the URL:
    http://openam.example.com:18080/openam/UI/Login?module=testModule
  2. If you need chain then explicitly specify the test chain:
    http://openam.example.com:18080/openam/UI/Login?service=testScript
  3. Use a test realm when testing new authentication modules, and use a test chain in this realm:
    http://openam.example.com:18080/openam/UI/Login?realm=test
If you didn't have that hindsight and you are reading this blog because you are currently locked out, you could do the inverse of the above, i.e. explicitly specify the known good modules/chains, or you could use the rather cool OpenAM notion of the Administrator's entry point.
This is accessed by visiting http://openam.example.com:18080/openam/console.
Doing this causes OpenAM to use the Administrator Authentication Configuration which is usually configured here:

This separate entry point is more usually used to demand stronger authentication for administration access, but it may just save your locked-out bacon too ;-)

Cheers,
- FB


Entering via the Administrator’s door

OpenAM's Authentication capabilities are pretty powerful (e.g. previous post), but as Spiderman almost said, "with great power comes great risk", and there is always the danger of locking yourself out. Having done this several times already this week, it's time to write down how to recover...

I was playing with a new OpenAM Authentication Module (more on this in a later blog) and I foolishly included the new module straight into the default authentication chain, so that when I encountered a bug I then couldn't login to correct the problem (or so I thought).

To limit the lockout risk, I guess I should have tested the module (ahead of putting it in the default chain) using one of these approaches:
  1. If the module can be executed standalone (rather than in a chain), explicitly specify the module in the URL:
    http://openam.example.com:18080/openam/UI/Login?module=testModule
  2. If you need chain then explicitly specify the test chain:
    http://openam.example.com:18080/openam/UI/Login?service=testScript
  3. Use a test realm when testing new authentication modules, and use a test chain in this realm:
    http://openam.example.com:18080/openam/UI/Login?realm=test
If you didn't have that hindsight and you are reading this blog because you are currently locked out, you could do the inverse of the above, i.e. explicitly specify the known good modules/chains, or you could use the rather cool OpenAM notion of the Administrator's entry point.
This is accessed by visiting http://openam.example.com:18080/openam/console.
Doing this causes OpenAM to use the Administrator Authentication Configuration which is usually configured here:

This separate entry point is more usually used to demand stronger authentication for administration access, but it may just save your locked-out bacon too ;-)

Cheers,
- FB


OpenAM and Adaptive Authentication

ForgeRock are all about Identity Relationship Management, about helping to deliver and protect great web based services to users, devices and "things".
But the secret to delivering a great service is in knowing exactly who you're talking to. This involves Authentication and that's just one of the functions of OpenAM, part of the Open Identity Stack from ForgeRock.

"Authentication" to many people means logging-in by supplying usernames and passwords which are checked against back-end directory servers, databases, or other systems. But with the massive adoption of Mobile technology there are an increasing number of alternative ways for users to reliably identify themselves including:

  • one time passwords (maybe sent via email or SMS)
  • PKI using certificates on devices
  • multi-factor authenticators (used to be security fobs but now increasingly phone Apps)
  • biometric authentication

...to name just a few.

OpenAM supports a vast array of authentication modules but what is v. cool is that these can be "chained" to deliver smarter, context-aware authentication. Let me explain...

Suppose I want to deliver a web-based service to my community members or customers. The service is pretty valuable so I want to make sure that only those people who subscribed to it can get it. Therefore, I want to use multi-factor authentication (MFA). But I've also had feedback from subscribers that says MFA is a pain when logging in frequently. So here's the plan:

  • At the first login attempt from a device we've never seen before we should require MFA;
  • subsequent logins from that device can use simple username/password;
  • but every 30 days I want to force MFA again, just to make sure.
In OpenAM you can create a chain that looks like this:

This says:
  1. collect username and password credentials from the user and ensure they're valid against the DataStore (in my case this was an LDAP directory); This must succeed (Required) before the chain continues;
  2. next, run the Adaptive authentication module of OpenAM. This is worthy of a whole blog post itself, but suffice to say that this was configured to look for a Device Cookie. If the cookie is present then we've got enough data to grant access. If not, we fall through to the HOTP (HMAC One-Time Password) module;
  3. The HOTP module knows the user is in the directory from step 1, so it looks for the email address (or cell phone for SMS delivery) and sends a One Time Password to the user with a time limited lifespan.
The user experience goes like this:
If I have typed in my credentials correctly, then the browser prompts me for a One Time Password, and before you can ask "where do I get one of those?", my phone goes "Ping" with, in my case, an email containing the said OTP.

Once I enter this, I am in to the site.
Now the cute thing is that the second time I visit this site, I don't need to enter a OTP because OpenAM set a Device cookie last time round.
Hence I have met all my objectives listed above, and both my security team and subscribers are happy.

Cheers,
- FB


P.S. A few details about the Adaptive Authentication Module Configuration: 

The Device Registration Cookie was enabled thus:
Where the Risk Score is enough to tip us over the Risk Threshold.

And don't forget to specify the Adaptive Auth Post Authentication Processing class in the Chain configuration:





OpenAM and Adaptive Authentication

ForgeRock are all about Identity Relationship Management, about helping to deliver and protect great web based services to users, devices and "things".
But the secret to delivering a great service is in knowing exactly who you're talking to. This involves Authentication and that's just one of the functions of OpenAM, part of the Open Identity Stack from ForgeRock.

"Authentication" to many people means logging-in by supplying usernames and passwords which are checked against back-end directory servers, databases, or other systems. But with the massive adoption of Mobile technology there are an increasing number of alternative ways for users to reliably identify themselves including:

  • one time passwords (maybe sent via email or SMS)
  • PKI using certificates on devices
  • multi-factor authenticators (used to be security fobs but now increasingly phone Apps)
  • biometric authentication

...to name just a few.

OpenAM supports a vast array of authentication modules but what is v. cool is that these can be "chained" to deliver smarter, context-aware authentication. Let me explain...

Suppose I want to deliver a web-based service to my community members or customers. The service is pretty valuable so I want to make sure that only those people who subscribed to it can get it. Therefore, I want to use multi-factor authentication (MFA). But I've also had feedback from subscribers that says MFA is a pain when logging in frequently. So here's the plan:

  • At the first login attempt from a device we've never seen before we should require MFA;
  • subsequent logins from that device can use simple username/password;
  • but every 30 days I want to force MFA again, just to make sure.
In OpenAM you can create a chain that looks like this:

This says:
  1. collect username and password credentials from the user and ensure they're valid against the DataStore (in my case this was an LDAP directory); This must succeed (Required) before the chain continues;
  2. next, run the Adaptive authentication module of OpenAM. This is worthy of a whole blog post itself, but suffice to say that this was configured to look for a Device Cookie. If the cookie is present then we've got enough data to grant access. If not, we fall through to the HOTP (HMAC One-Time Password) module;
  3. The HOTP module knows the user is in the directory from step 1, so it looks for the email address (or cell phone for SMS delivery) and sends a One Time Password to the user with a time limited lifespan.
The user experience goes like this:
If I have typed in my credentials correctly, then the browser prompts me for a One Time Password, and before you can ask "where do I get one of those?", my phone goes "Ping" with, in my case, an email containing the said OTP.

Once I enter this, I am in to the site.
Now the cute thing is that the second time I visit this site, I don't need to enter a OTP because OpenAM set a Device cookie last time round.
Hence I have met all my objectives listed above, and both my security team and subscribers are happy.

Cheers,
- FB


P.S. A few details about the Adaptive Authentication Module Configuration: 

The Device Registration Cookie was enabled thus:
Where the Risk Score is enough to tip us over the Risk Threshold.

And don't forget to specify the Adaptive Auth Post Authentication Processing class in the Chain configuration:





FatBloke – The Reboot

Once upon a time in a distant galaxy, FatBloke told stories of the greatness of VirtualBox and SGD.

But there are always new stories to be told: stories of great wonder, stories of identity and of clouds, of mobile apps and of security, of business opportunity and success. And they will start to appear here as the FatBloke rediscovers his voice to sing a new song....

[to be continued...]

- FB

FatBloke – The Reboot

Once upon a time in a distant galaxy, FatBloke told stories of the greatness of VirtualBox and SGD.

But there are always new stories to be told: stories of great wonder, stories of identity and of clouds, of mobile apps and of security, of business opportunity and success. And they will start to appear here as the FatBloke rediscovers his voice to sing a new song....

[to be continued...]

- FB