What’s New in ForgeRock Access Management 5?

ForgeRock this week released version 5 of the ForgeRock Identity Platform of which ForgeRock Access Management 5 is a major component. So, what's new in this release?

New Name

The eagle-eyed amongst you may be asking yourselves about that name and version. ForgeRock Access Management is the actually the new name for what was previously known as OpenAM. And as all components of the Platform are now at the same version, this becomes AM 5.0 rather than OpenAM 14.0 (though you may still see remnants of the old versioning under the hood).

Cloud Friendly

AM5 is focussed on being a great Identity Platform for Consumer IAM and IoT and one of the shared characteristics of these markets is high, unpredictable scale. So one of the design goals of AM5 was to become more cloud-friendly enabling a more elastic architecture. This has resulted in a simpler architectural model where individual AM servers no longer need to know about, or address, other AM servers in a cluster, they can act Autonomously. If you need more horsepower, simply spin up new instances of AM. 

DevOps Friendly

To assist with the casual "Spin up new instances" statement above, AM5 has become more DevOps friendly. Firstly, the configuration APIs to AM are now available over REST, meaning configuration can be done remotely. Secondly, there's a great new tool called Amster.
Amster is a lightweight command-line tool which can run in interactive shell mode, or be scripted.

A typical Amster script looks like this:
connect http://www.example.com:8080/openam -k /Users/demo/keyfile
import-config --path /Users/demo/am-config 
:exit
This example connects to the remote AM5 instance, authenticating using a key, then imports configuration from the filesystem/git repo, before exiting.
Amster is separately downloadable has its own documentation too.

Developer Friendly

AM5 comes with new interactive documentation via the API Explorer. This is a Swagger-like interface describing all of the AM CREST (Common REST) APIs and means it is now easier than ever for devs to understand how to use these APIs. Not only are the Request parameters fully documented with Response results, but devs can "Try it out" there and then.

Secure OAuth2 Tokens

OAuth2 is great, and used everywhere. Mobile apps, Web apps, Micro-services and, more and more, in IoT.
But one of the problems with OAuth2 access tokens are that they are bearer tokens. This means that if someone steals it, they can use it to get access to the services it grants access to.
One way to prevent this is to adopt a new industry standard approach called "Proof of Possession"(PoP).
With PoP the client provides something unique to it, which is baked into the token when it is issued by AM. This is usually the public key of the client. The Resource Server, when presented with such a token, can use the confirmation claim/key to challenge the client, knowing that only the true-client can successfully answer the challenge.

Splunk Audit Handler

Splunk is one of the cool kids so it makes sense that our pluggable Audit Framework supports a native Splunk handler


There are a tonne of other improvements to AM5 we don't have time to cover but read about some of the others in the Release Notes, or download it from Backstage now and give it a whirl.

What’s New in ForgeRock Access Management 5?

ForgeRock this week released version 5 of the ForgeRock Identity Platform of which ForgeRock Access Management 5 is a major component. So, what's new in this release?

New Name

The eagle-eyed amongst you may be asking yourselves about that name and version. ForgeRock Access Management is the actually the new name for what was previously known as OpenAM. And as all components of the Platform are now at the same version, this becomes AM 5.0 rather than OpenAM 14.0 (though you may still see remnants of the old versioning under the hood).

Cloud Friendly

AM5 is focussed on being a great Identity Platform for Consumer IAM and IoT and one of the shared characteristics of these markets is high, unpredictable scale. So one of the design goals of AM5 was to become more cloud-friendly enabling a more elastic architecture. This has resulted in a simpler architectural model where individual AM servers no longer need to know about, or address, other AM servers in a cluster, they can act Autonomously. If you need more horsepower, simply spin up new instances of AM. 

DevOps Friendly

To assist with the casual "Spin up new instances" statement above, AM5 has become more DevOps friendly. Firstly, the configuration APIs to AM are now available over REST, meaning configuration can be done remotely. Secondly, there's a great new tool called Amster.
Amster is a lightweight command-line tool which can run in interactive shell mode, or be scripted.

A typical Amster script looks like this:
connect http://www.example.com:8080/openam -k /Users/demo/keyfile
import-config --path /Users/demo/am-config 
:exit
This example connects to the remote AM5 instance, authenticating using a key, then imports configuration from the filesystem/git repo, before exiting.
Amster is separately downloadable has its own documentation too.

Developer Friendly

AM5 comes with new interactive documentation via the API Explorer. This is a Swagger-like interface describing all of the AM CREST (Common REST) APIs and means it is now easier than ever for devs to understand how to use these APIs. Not only are the Request parameters fully documented with Response results, but devs can "Try it out" there and then.

Secure OAuth2 Tokens

OAuth2 is great, and used everywhere. Mobile apps, Web apps, Micro-services and, more and more, in IoT.
But one of the problems with OAuth2 access tokens are that they are bearer tokens. This means that if someone steals it, they can use it to get access to the services it grants access to.
One way to prevent this is to adopt a new industry standard approach called "Proof of Possession"(PoP).
With PoP the client provides something unique to it, which is baked into the token when it is issued by AM. This is usually the public key of the client. The Resource Server, when presented with such a token, can use the confirmation claim/key to challenge the client, knowing that only the true-client can successfully answer the challenge.

Splunk Audit Handler

Splunk is one of the cool kids so it makes sense that our pluggable Audit Framework supports a native Splunk handler


There are a tonne of other improvements to AM5 we don't have time to cover but read about some of the others in the Release Notes, or download it from Backstage now and give it a whirl.

Using Push Notifications for Passwordless Authentication and Easy MFA



There is often a trade-off between the convenience of an authentication system and the strength of security around it. Oftentimes, the stronger the security, the more tedious it can be for the end user. But now that (almost) everyone has a smartphone, can we somehow use this magical device as an authenticator?

The mid-year release of the ForgeRock Identity Platform introduced some exciting new Access Management technology, namely Push Authentication. When a user wants to login, they simply identify themselves (e.g. username or email) and the system sends them a Push Notification message asking if they want to authorize the login. This message is fielded by the ForgeRock Authenticator App (iPhone or Android) and the user can use swipe or TouchId to agree to the authentication attempt, or Cancel to deny it. Cool stuff, let's check it out...

We'll look at:

  • The User experience of logging in using Push Auth
  • The Architecture underpinning this
  • The Admin experience of setting this up
  • Customizing the experience

User Experience

Before you can use Push you'll need to register your phone to your account so you'll typically login in the traditional way...


...before being presented with a QR code...

Using the ForgeRock Authenticator app on your phone you can scan this to create an account for that IDP...

Now when the user wants to login, they can simply enter their username...

...and their phone buzzes and displays something like this...



The user decides if this is a login attempt by them and, if so, uses TouchId (or swipe if TouchId not present or enabled) to get logged in.

The Architecture

The players in this dance are:

  • The user on their primary device (say laptop, but could be phone too, see later);
  • The ForgeRock AM server;
  • The Push Service in the Cloud;
  • The phone.



How to set it up (The administrator's experience)

To set this up we'll need:

  • ForgeRock Access Management (AM) version 13.5;
  • We'll create 2 new authentication module instances
    • ForgeRock Authenticator (Push) Registration - used to link phone to account;
    • ForgeRock Authenticator (Push) - used when logging in;
  • We'll create a new realm-based Push Notification Service - this is how AM talks to the Cloud push service;

Authentication Modules and Chains

First, in the AM Admin Console, create the 2 new authentication modules (let's call them Push-Reg and Push-Auth) and use the default values....
 
They will look something like this...




Now create 2 Authentication Chains, also called Push-Auth and Push-Reg.

For Push-Reg we'll use a simple Datastore (username/password) module, to identify the user during registration, followed by the Push-Reg Authentication module, and to keep things simple, lets just use the Push-Auth module in the Push-Auth chain...



So now we have 2 new chains...



At this point you can test these chains out by visiting
<deployment-url>/XUI/#login/&service=Push-Auth
where Push-Auth is the chain name.

But this won't work yet because we need to tell AM how to send Push Notifications by creating the Push Notification Service.

Push Notification Service

The Admin Console has changed a bit in 13.5 in the Services area and is now much easier to configure. First, create a New Service of type Push Notification Service...



Once created, we want to configure this. This is slightly tricky but not too hard for people who have read this far ;-)

At the time of writing, ForgeRock use AWS Simple Notification Service for sending Push Notifications to Android and Apple phones. And ForgeRock have provided a convenient way for customers to generate credentials to configure this Service.




Go to Backstage, login and navigate to Projects. If you haven't registered a Project before, create one and also an Environment too within the Project. Then simply press the big button marked "Set Up Push Auth Credentials"
This will generate some credentials which you can use to populate the Push Notification Service on your AM deployment.



Providing your phone can reach your AM server, your users should now be able to register and login using Push Notifications.

Customizing the IDPs

Say you now want to customize the IDP to have your corporate logo and colorscheme.
Return to the Push-Reg Auth Module and you'll see that you can configure Issuer Name, background color and Logo.

And in the Push-Auth Module you can tailor the message that is presented to the user.

This all means that on your phone you can deliver an experience like this....



Summary

This was a simple "getting you going" blog entry, and I hope we've now achieved that.

In internet facing deployments you may want to use more of the capability of AM's Authentication Chains to use Push as a super-easy 2FA offering, or if you want to deliver a Passwordless experience, put more intelligence around detecting the identity of the user attempting to login to prevent unsolicited Push messages being sent to a user.



Using Push Notifications for Passwordless Authentication and Easy MFA

There is often a trade-off between the convenience of an authentication system and the strength of security around it. Oftentimes, the stronger the security, the more tedious it can be for the end user. But now that (almost) everyone has a smartphone, can we somehow use this magical device as an authenticator?

The mid-year release of the ForgeRock Identity Platform introduced some exciting new Access Management technology, namely Push Authentication. When a user wants to login, they simply identify themselves (e.g. username or email) and the system sends them a Push Notification message asking if they want to authorize the login. This message is fielded by the ForgeRock Authenticator App (iPhone or Android) and the user can use swipe or TouchId to agree to the authentication attempt, or Cancel to deny it. Cool stuff, let's check it out...

We'll look at:

  • The User experience of logging in using Push Auth
  • The Architecture underpinning this
  • The Admin experience of setting this up
  • Customizing the experience

User Experience

Before you can use Push you'll need to register your phone to your account so you'll typically login in the traditional way...

...before being presented with a QR code...

Using the ForgeRock Authenticator app on your phone you can scan this to create an account for that IDP...
Now when the user wants to login, they can simply enter their username...
...and their phone buzzes and displays something like this...
The user decides if this is a login attempt by them and, if so, uses TouchId (or swipe if TouchId not present or enabled) to get logged in. 

The Architecture

The players in this dance are:
  1. The user on their primary device (say laptop, but could be phone too, see later);
  2. The ForgeRock AM server;
  3. The Push Service in the Cloud;
  4. The phone.


How to set it up (The administrator's experience)

To set this up we'll need:
  • ForgeRock Access Management (AM) version 13.5;
  • We'll create 2 new authentication module instances 
    • ForgeRock Authenticator (Push) Registration - used to link phone to account;
    • ForgeRock Authenticator (Push) - used when logging in;
  • We'll create a new realm-based Push Notification Service - this is how AM talks to the Cloud push service;

Authentication Modules and Chains

First, in the AM Admin Console, create the 2 new authentication modules (let's call them Push-Reg and Push-Auth) and use the default values....

They will look something like this...

Now create 2 Authentication Chains, also called Push-Auth and Push-Reg.
For Push-Reg we'll use a simple Datastore (username/password) module, to identify the user during registration, followed by the Push-Reg Authentication module...
and to keep things simple, lets just use the Push-Auth module in the Push-Auth chain...
So now we have 2 new chains...

At this point you can test these chains out by visiting
<deployment-url>/XUI/#login/&service=Push-Auth
where Push-Auth is the chain name.
But this won't work yet because we need to tell AM how to send Push Notifications by creating the Push Notification Service.

Push Notification Service

The Admin Console has changed a bit in 13.5 in the Services area and is now much easier to configure. First, create a New Service of type  Push Notification Service...

 

Once created, we want to configure this. This is slightly tricky but not too hard for people who have read this far ;-)

At the time of writing, ForgeRock use AWS Simple Notification Service for sending Push Notifications to Android and Apple phones. And ForgeRock have provided a convenient way for customers to generate credentials to configure this Service.

Go to Backstage, login and navigate to Projects. If you haven't registered a Project before, create one and also an Environment too within the Project. Then simply press the big button marked "Set Up Push Auth Credentials"



This will generate some credentials which you can use to populate the Push Notification Service on your AM deployment.

Providing your phone can reach your AM server, your users should now be able to register and login using Push Notifications.

Customizing the IDPs

Say you now want to customize the IDP to have your corporate logo and colorscheme.

Return to the Push-Reg Auth Module and you'll see that you can configure Issuer Name, background color and Logo.
And in the Push-Auth Module you can tailor the message that is presented to the user.
This all means that on your phone you can deliver an experience like this....












Summary

This was a simple "getting you going" blog entry.

In internet facing deployments you may want to use more of the capability of AM's Authentication Chains to use Push as a super-easy 2FA offering, or if you want to deliver a Passwordless experience, put more intelligence around detecting the identity of the user attempting to login to prevent unsolicited Push messages being sent to a user.


Using your phone with a mobile OpenAM demo environment

(Another blog which is a memo-to-self)

Here's the problem:

  • My OpenAM server is running on Tomcat on my Mac
  • My Mac (which is a client machine really) moves with me across different networks, getting different network addresses as it goes
  • My phone needs to connect to my Mac using a dns name
  • And for a bonus point, in order to demo upcoming Push Authentication:
    • the Mac needs to be connected to the Internet;
    • the phone needs to be connected to a data connection.
So I need a setup like this:

DNS Server

The key to getting this setup to work is to run a DNS server on the Mac. I used the excellent dnsmasq which by default uses the /etc/hosts file on the Mac as its source of information.
So in my /etc/hosts I have something like:

10.0.1.99 ahall.forgerock.com ahall.forgerock.dev ahall
where 10.0.1.99 is the IP address of my Mac on the wireless network.

Phone Settings

Then I configured my iPhone (which has to be on the same WiFi) to point to the Mac as a DNS server.  Go to Settings...Wifi...click on the "i" and add the Mac's IP address (i.e. 10.0.1.99) as a DNS Server, ahead of the usual DNS Servers you may use (such as 8.8.8.8).



While trying to get this to work, I found that occasionally I had to stop and start dnsmasq:
# sudo launchctl stop homebrew.mxcl.dnsmasq
# sudo launchctl start homebrew.mxcl.dnsmasq
...especially after making changes to /etc/hosts.

(You may also find that Dyn Dig is a useful tool to have at hand. It is a mobile app version of the DNS resolution tool dig.)

On the Move

What this setup does require is that when your Mac moves to a different WiFi network or, in general, gets a different IP address, you will clearly need to change your /etc/hosts and Phone settings again. So it is not a perfect solution.
But it does mean I can test OpenAM from my phone:



HTH
/FB

Using your phone with a mobile OpenAM demo environment

(Another blog which is a memo-to-self)

Here's the problem:

  • My OpenAM server is running on Tomcat on my Mac
  • My Mac (which is a client machine really) moves with me across different networks, getting different network addresses as it goes
  • My phone needs to connect to my Mac using a dns name
  • And for a bonus point, in order to demo upcoming Push Authentication:
    • the Mac needs to be connected to the Internet;
    • the phone needs to be connected to a data connection.
So I need a setup like this:

DNS Server

The key to getting this setup to work is to run a DNS server on the Mac. I used the excellent dnsmasq which by default uses the /etc/hosts file on the Mac as its source of information.
So in my /etc/hosts I have something like:

10.0.1.99 ahall.forgerock.com ahall.forgerock.dev ahall
where 10.0.1.99 is the IP address of my Mac on the wireless network.

Phone Settings

Then I configured my iPhone (which has to be on the same WiFi) to point to the Mac as a DNS server.  Go to Settings...Wifi...click on the "i" and add the Mac's IP address (i.e. 10.0.1.99) as a DNS Server, ahead of the usual DNS Servers you may use (such as 8.8.8.8).



While trying to get this to work, I found that occasionally I had to stop and start dnsmasq:
# sudo launchctl stop homebrew.mxcl.dnsmasq
# sudo launchctl start homebrew.mxcl.dnsmasq
...especially after making changes to /etc/hosts.

(You may also find that Dyn Dig is a useful tool to have at hand. It is a mobile app version of the DNS resolution tool dig.)

On the Move

What this setup does require is that when your Mac moves to a different WiFi network or, in general, gets a different IP address, you will clearly need to change your /etc/hosts and Phone settings again. So it is not a perfect solution.
But it does mean I can test OpenAM from my phone:



HTH
/FB

OpenAM 12 and Social Authentication

Many OpenAM deployments are consumer-facing where organizations are looking to deliver a great service to their existing, and new, customers. Earlier, we talked about how self-service registration in OpenAM 12 makes it easy for new customers to sign up, but even a simple web form is too much trouble for some people (myself included).

So the arrival of Social Authentication in OpenAM 12 is warmly welcomed. This means that administrators can quickly roll out support for social identities, from the likes of Google, Facebook and Microsoft, and customers or users get a great new way to sign in by simply clicking on the social Identity Provider (IDP) logo.
No more registration forms, just easy and rapid access to your OpenAM protected service.

Here's how it works:

Overview

The OpenAM administrator needs an account with the relevant IDP but then he simply:
  1. Registers the OpenAM server deployment as a Client App with the Social IDP;
  2. Configures OpenAM using these newly created Client App ID details at the IDP;
  3. That's it! Users can now login using their Google/Facebook/Microsoft credentials.

Configuration

(In this example we'll use Google but the same basic procedure is used with all the IDPs.)
Firstly, I go to my Social IDP registration page. At the time of writing these are:
...and create a project or app.

With Google it goes like this (click on the screenshots to zoom in):
(1) Create a Project:

(1a) For Google, we also need to enable the Google+ API:

(2) In a separate browser window, go to the Administration Console of OpenAM, go to the Common Tasks pane and click on the appropriate IDP, Google in our case:

(3) Copy the pre-filled Redirect URL from OpenAM:
(4) Now return to the Google developer console browser window and create a new Client ID:


(5) Paste the previously copied Redirect URL to associate it with this Client ID:

(6) Now copy the Google Client ID and Secret and paste them back into OpenAM:

(7) On clicking Create, OpenAM uses this information to automatically configure:

  1. An OAuth2/OpenID Connect authentication module;
  2. An authentication chain containing this authentication module;
  3. A social service which can be queried by the OpenAM user interface or other REST clients to get information about the configured social authentication providers.



User Experience

Now we'll look at the user experience...
(1) When the login page is reached the new OpenAM 12 XUI, which is a smart javascript client, queries the REST endpoint of the social authentication service to discover what is available. This endpoint provides a logo which is displayed as part of the login dialog:


(2) When the user clicks on this logo, she is redirected to the social authentication page:

(3) The first time the user does this a consent page is displayed:

(4) and on Accepting this, the user is logged in to OpenAM:


OpenAM can optionally create new accounts based on data gleaned from the social IDP so that services using OpenAM can identify and provide a rich experience to returning social users.

Summary

Social Authentication in OpenAM 12 takes only a few minutes for administrators to configure.
For sites looking to make life as easy as possible for new customers or users, Social Authentication is a great option.

- FB


OpenAM 12 and Social Authentication

Many OpenAM deployments are consumer-facing where organizations are looking to deliver a great service to their existing, and new, customers. Earlier, we talked about how self-service registration in OpenAM 12 makes it easy for new customers to sign up, but even a simple web form is too much trouble for some people (myself included).

So the arrival of Social Authentication in OpenAM 12 is warmly welcomed. This means that administrators can quickly roll out support for social identities, from the likes of Google, Facebook and Microsoft, and customers or users get a great new way to sign in by simply clicking on the social Identity Provider (IDP) logo.
No more registration forms, just easy and rapid access to your OpenAM protected service.

Here's how it works:

Overview

The OpenAM administrator needs an account with the relevant IDP but then he simply:
  1. Registers the OpenAM server deployment as a Client App with the Social IDP;
  2. Configures OpenAM using these newly created Client App ID details at the IDP;
  3. That's it! Users can now login using their Google/Facebook/Microsoft credentials.

Configuration

(In this example we'll use Google but the same basic procedure is used with all the IDPs.)
Firstly, I go to my Social IDP registration page. At the time of writing these are:
...and create a project or app.

With Google it goes like this (click on the screenshots to zoom in):
(1) Create a Project:

(1a) For Google, we also need to enable the Google+ API:

(2) In a separate browser window, go to the Administration Console of OpenAM, go to the Common Tasks pane and click on the appropriate IDP, Google in our case:

(3) Copy the pre-filled Redirect URL from OpenAM:
(4) Now return to the Google developer console browser window and create a new Client ID:


(5) Paste the previously copied Redirect URL to associate it with this Client ID:

(6) Now copy the Google Client ID and Secret and paste them back into OpenAM:

(7) On clicking Create, OpenAM uses this information to automatically configure:

  1. An OAuth2/OpenID Connect authentication module;
  2. An authentication chain containing this authentication module;
  3. A social service which can be queried by the OpenAM user interface or other REST clients to get information about the configured social authentication providers.



User Experience

Now we'll look at the user experience...
(1) When the login page is reached the new OpenAM 12 XUI, which is a smart javascript client, queries the REST endpoint of the social authentication service to discover what is available. This endpoint provides a logo which is displayed as part of the login dialog:


(2) When the user clicks on this logo, she is redirected to the social authentication page:

(3) The first time the user does this a consent page is displayed:

(4) and on Accepting this, the user is logged in to OpenAM:


OpenAM can optionally create new accounts based on data gleaned from the social IDP so that services using OpenAM can identify and provide a rich experience to returning social users.

Summary

Social Authentication in OpenAM 12 takes only a few minutes for administrators to configure.
For sites looking to make life as easy as possible for new customers or users, Social Authentication is a great option.

- FB


The Persistent Cookie Authentication Module

How long should a session last?

I guess we all get fed up when we are asked to log in to a web site over, and over again. So when protecting your resources, it is important that an admin chooses the "right" session length.

But what is "right" depends on your resources and how tightly you'd like to protect them. Some people might want a short session length because the content may be extremely valuable and you want the user to prove that he is still the same guy.

But for other sites and resources, you may want to err on the side of convenience for the user and have a long session lifetime, maybe even stretching beyond the lifetime of a browser session. For example, the "Remember me for a week" feature seen here...


If you want to provide a long-lived session, you might want to consider the OpenAM 12 Persistent Cookie authentication module.

Here's how it could work:

Administrator experience

  1. Create a new Persistent Cookie authentication module and set the length of your session. (Note to self - Remember that if you use a Secure Cookie, the session must be over https else the browser will not submit it.)
  2. Create an authentication chain (here called "test")with the Persistent Cookie module first and mark it as sufficient.
  3. On the same Authentication Chain page, add the Persistent Cookie auth module to the Post authentication processing class for this chain. 
  4. Assign the chain to the realm you want this to work with.

User Experience

  1. The first time the user hits your site there will be no persistent cookie so the chain means you'll fall through to login using the usual method (whatever that is).
  2. On a successful login, the Post Authentication processing will store a persistent cookie. You can examine this using cookie tools like the Cookies app for Chrome or Firefox.
  3. Close the browser, logout of your PC, make a cup of tea, whatever.
  4. When you next start up the browser and return to the site you will get straight to your resources and this will continue to happen for the configured lifetime of the Persistent Cookie.
In case you're interested, the Persistent Cookie is a JWT and by default is called "session-jwt", and you can also mess around with idle times too, but this is left as an exercise to the reader ;-)

Hope this helps someone out there.
-FB

The Persistent Cookie Authentication Module

How long should a session last?

I guess we all get fed up when we are asked to log in to a web site over, and over again. So when protecting your resources, it is important that an admin chooses the "right" session length.

But what is "right" depends on your resources and how tightly you'd like to protect them. Some people might want a short session length because the content may be extremely valuable and you want the user to prove that he is still the same guy.

But for other sites and resources, you may want to err on the side of convenience for the user and have a long session lifetime, maybe even stretching beyond the lifetime of a browser session. For example, the "Remember me for a week" feature seen here...


If you want to provide a long-lived session, you might want to consider the OpenAM 12 Persistent Cookie authentication module.

Here's how it could work:

Administrator experience

  1. Create a new Persistent Cookie authentication module and set the length of your session. (Note to self - Remember that if you use a Secure Cookie, the session must be over https else the browser will not submit it.)
  2. Create an authentication chain (here called "test")with the Persistent Cookie module first and mark it as sufficient.
  3. On the same Authentication Chain page, add the Persistent Cookie auth module to the Post authentication processing class for this chain. 
  4. Assign the chain to the realm you want this to work with.

User Experience

  1. The first time the user hits your site there will be no persistent cookie so the chain means you'll fall through to login using the usual method (whatever that is).
  2. On a successful login, the Post Authentication processing will store a persistent cookie. You can examine this using cookie tools like the Cookies app for Chrome or Firefox.
  3. Close the browser, logout of your PC, make a cup of tea, whatever.
  4. When you next start up the browser and return to the site you will get straight to your resources and this will continue to happen for the configured lifetime of the Persistent Cookie.
In case you're interested, the Persistent Cookie is a JWT and by default is called "session-jwt", and you can also mess around with idle times too, but this is left as an exercise to the reader ;-)

Hope this helps someone out there.
-FB