Integrating ForgeRock Identity Platform 6.5

Integrating The ForgeRock Identity Platform 6.5

It’s a relatively common requirement to need to integrate the products that make up the ForgeRock Identity Platform. The IDM Samples Guide contains a good working example of just how to do this. Each version of the ForgeRock stack has slight differences, both in the products themselves, as well as the integrations. As such this blog will focus on version 6.5 of the products and will endeavour to include as much useful information to speed integrations for readers of this blog, including sample configuration files, REST calls etc.

In this integration IDM acts as an OIDC Relying Party, talking to AM as the OIDC Provider using the OAuth 2.0 authorization grant. The following sequence diagram illustrates successful processing from the authorization request, through grant of the authorization code, and ID token from the authorization provider, AM. You can find more details in the IDM Samples Guide.

Full Stack Authorization Code Flow

Sample files

For this integration I’ve included configured sample files which can be found by accessing the link below, modified, and either used as an example or just dropped straight into your test environment. It should not have to be said but just in case…DO NOT deploy these to production without appropriate testing / hardening: https://stash.forgerock.org/users/mark.nienaber_forgerock.com/repos/fullstack6.5/.

Postman Collection

For any REST calls made in this blog you’ll find the Postman collection available here: https://documenter.getpostman.com/view/5814408/SVfJVBYR?version=latest

Sample Scripts

We will set up some basic vanilla instances of our products to get started. I’ve provided some scripts to install both DS as well as AM.

Products used in this integration

Documentation can be found https://backstage.forgerock.com/docs/.

Note: In this blog I install the products under my home directory, this is not best practice, but keep in mind the focus is on the integration, and not meant as a detailed install guide.

Setup new DS instances

On Server 1 (AM Server) install a fresh DS 6.5 instance for an external AM config store (optional) and a DS repository to be shared with IDM.

Add the following entries to the hosts file:

sudo vi /etc/hosts
127.0.0.1       localhost opendj.example.com amconfig1.example.com openam.example.com

Before running the DS install script you’ll need to copy the Example.ldif file from the full-stack IDM sample to the DS/AM server. You can do this manually or use SCP from the IDM server.

scp ~/openidm/samples/full-stack/data/Example.ldif fradmin@opendj.example.com:~/Downloads

Modify the sample file installDSFullStack6.5.sh including:

  • server names
  • port numbers
  • location of DS-6.5.0.zip file
  • location of the Example.ldif from the IDM full-stack sample.

Once completed, run to install both an external AM Config store as well as the DS shared repository. i.e.

script_dir=`pwd`
ds_zip_file=~/Downloads/DS/DS-6.5.0.zip
ds_instances_dir=~/opends/ds_instances
ds_config=${ds_instances_dir}/config
ds_fullstack=${ds_instances_dir}/fullstack
#IDMFullStackSampleRepo
ds_fullstack_server=opendj.example.com
ds_fullstack_server_ldapPort=5389
ds_fullstack_server_ldapsPort=5636
ds_fullstack_server_httpPort=58081
ds_fullstack_server_httpsPort=58443
ds_fullstack_server_adminConnectorPort=54444
#Config
ds_amconfig_server=amconfig1.example.com
ds_amconfig_server_ldapPort=3389
ds_amconfig_server_ldapsPort=3636
ds_amconfig_server_httpPort=38081
ds_amconfig_server_httpsPort=38443
ds_amconfig_server_adminConnectorPort=34444

Now let’s run the script on Server 1, the AM / DS server, to create a new DS instances.

chmod +x ./installdsFullStack.sh
./installdsFullStack.sh
Install DS instances

You now have 2 DS servers installed and configured, let’s install AM.

Setup new AM server

On Server 1 we will install a fresh AM 6.5.2 on Tomcat using the provided Amster script.

Assuming the tomcat instance is started drop the AM WAR file under the webapps directory renaming the context to secure (change this as you wish).

cp ~/Downloads/AM-6.5.2.war ~/tomcat/webapps/secure.war

Copy the amster script install_am.amster into your amster 6.5.2 directory and make any modifications as required.

install-openam 
--serverUrl http://openam.example.com:8080/secure 
--adminPwd password 
--acceptLicense 
--cookieDomain example.com 
--cfgStoreDirMgr 'uid=am-config,ou=admins,ou=am-config' 
--cfgStoreDirMgrPwd password 
--cfgStore dirServer 
--cfgStoreHost amconfig1.example.com 
--cfgStoreAdminPort 34444 
--cfgStorePort 3389 
--cfgStoreRootSuffix ou=am-config 
--userStoreDirMgr 'cn=Directory Manager' 
--userStoreDirMgrPwd password 
--userStoreHost opendj.example.com  
--userStoreType LDAPv3ForOpenDS 
--userStorePort 5389 
--userStoreRootSuffix dc=example,dc=com
:exit

Now run amster and pass it this script to install AM. You can do this manually if you like, but scripting will make your life easier and allow you to repeat it later on.

cd amster6.5.2/
./amster install_am.amster
Install AM

At the end of this you’ll have AM installed and configured to point to the DS instances you set up previously.

AM Successfully installed

Setup new IDM server

On Server 2 install/unzip a new IDM 6.5.0.1 instance.

Make sure the IDM server can reach AM and DS servers by adding an entry to the hosts file.

sudo vi /etc/hosts
Hosts file entry

Modify the hostname and port of the IDM instance in the boot.properties file. An example boot.properties file can be found HERE.

cd ~/openidm
vi /resolver/boot.properties

Set appropriate openidm.host and openidm.port.http/s.

openidm/resolver/boot.properties

We now have the basic AM / IDM and DS setup and are ready to configure each of the products.

Configure IDM to point to shared DS repository

Modify the IDM LDAP connector file to point to the shared repository. An example file can be found HERE.

vi ~/openidm/samples/full-stack/conf/provisioner.openicf-ldap.json

Change “host” and “port” to match shared repo configured above.

provisioner.openicf-ldap.json

Configure AM to point to shared DS repository

Login as amadmin and browse to Identity Stores in the realm you’re configuring. For simplicity I’m using Top Level Realm , DO NOT this in production!!.

Set the correct values for your environment, then select Load Schema and Save.

Shared DS Identity Store

Browse to Identities and you should now see two identities that were imported in the Example.ldif when you setup the DS shared repository.

List of identities

We will setup another user to ensure AM is configured to talk to DS correctly. Select + Add Identity and fill in the values then press Create.

Create new identity

Modify some of the users values and press Save Changes.

Modify attributes

Prepare IDM

We will start IDM now and check that it’s connected to the DS shared repository.

Start the IDM full-stack sample

Enter the following commands to start the full-stack sample.

cd ~/openidm/
./startup.sh -p samples/full-stack
Start full-stack sample

Login to IDM

Login to the admin interface as openidm-admin.

http://openidm.example.com:8080/admin/

Login as openidm-admin

Reconcile DS Shared Repository

We will now run a reconciliation to pull users from the DS shared repository into IDM.

Browse to Configure, then Mappings then on the System/ldap/account→Mananged/user mapping select Reconcile

Reconcile DS shared repository

The users should now exist under Manage, Users.

User list

Let’s Login with our newly created testuser1 to make sure it’s all working.

End User UI Login

You should see the welcome screen.

Welcome Page

IDM is now ready for integration with AM.

Configure AM for integration

Now we will set up AM for integration with IDM.

Setup CORS Filter

Set up a CORS filter in AM to allow IDM as an origin. An example web.xml can be found HERE.

vi tomcat/webapps/secure/WEB-INF/web.xml

Add the appropriate CORS filter. (See sample file above)

</filter-mapping>
<filter-mapping>
<filter-name>CORSFilter</filter-name>
<url-pattern>/json/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CORSFilter</filter-name>
<url-pattern>/oauth2/*</url-pattern>
</filter-mapping>
<filter>
<filter-name>CORSFilter</filter-name>
<filter-class>org.forgerock.openam.cors.CORSFilter</filter-class>
<init-param>
<param-name>methods</param-name>
<param-value>POST,PUT,OPTIONS</param-value>
</init-param>
<init-param>
<param-name>origins</param-name>
<param-value>http://openidm.example.com:8080,http://openam.example.com:8080,http://localhost:8000,http://localhost:8080,null,file://</param-value>
</init-param>
<init-param>
<param-name>allowCredentials</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>headers</param-name>
<param-value>X-OpenAM-Username,X-OpenAM-Password,X-Requested-With,Accept,iPlanetDirectoryPro</param-value>
</init-param>
<init-param>
<param-name>expectedHostname</param-name>
<param-value>openam.example.com:8080</param-value>
</init-param>
<init-param>
<param-name>exposeHeaders</param-name>
<param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials,Set-Cookie</param-value>
</init-param>
<init-param>
<param-name>maxAge</param-name>
<param-value>1800</param-value>
</init-param>
</filter>

Configure AM as an OIDC Provider

Login to AM as an administrator and browse to the Realm you’re configuring. As already mentioned, I’m using the Top Level Realm for simplicity.

Once you’ve browsed to the Realm, on the Dashboard, select Configure OAuth Provider.

Configure OAuth Provider

Now select Configure OpenID Connect.

Configure OIDC

If you need to modify any values like the Realm then do, but I’ll just press Create.

OIDC Server defaults

You’ll get a success message.

Success

AM is now configured as an OP, let’s set some required values. Browse to Services, then click on OAuth2 Provider.

AM Services

On the Consent tab, check the box next to Allow Clients to Skip Consent, then press Save.

Consent settings

Now browse to the Advanced OpenID Connect tab set openidm as the value for Authorized OIDC SSO Clients ( this is the name of the Relying Party / Client which we will create next). Press Save.

Authorized SSO clients

Configure Relying Party / Client for IDM

You can do these steps manually but let’s call AM’s REST interface, you can save these calls and easily replicate this step with the click of a button if you use a tool like Postman (See HERE for the Postman collection). I am using a simple CURL command from the AM server.

Firstly we’ll need an AM administrator session to create the client so call the /authenticate endpoint. (I’ve used jq for better formatting, so I’ll leave that for you to add in if required)

curl -X POST 
http://openam.example.com:8080/secure/json/realms/root/authenticate 
-H 'Accept-API-Version: resource=2.0, protocol=1' 
-H 'Content-Type: application/json' 
-H 'X-OpenAM-Password: password' 
-H 'X-OpenAM-Username: amadmin' 
-H 'cache-control: no-cache' 
-d '{}'

The SSO Token / Session will be returned as tokenId, so save this value.

Authenticate

Now we have a session we can use that in the next call to create the client. Again this will be done via REST however you can do this manually if you want. Substitute the tokenId value from above for the value of the iPlanetDrectoryPro.

curl -X POST 
'http://openam.example.com:8080/secure/json/realms/root/agents/?_action=create' 
-H 'Accept-API-Version: resource=3.0, protocol=1.0' 
-H 'Content-Type: application/json' 
-H 'iPlanetDirectoryPro: djyfFX3h97jH2P-61auKig_i23o.*AAJTSQACMDEAAlNLABxFc2d0dUs2c1RGYndWOUo0bnU3dERLK3pLY2c9AAR0eXBlAANDVFMAAlMxAAA.*' 
-d '{
"username": "openidm",
"userpassword": "openidm",
"realm": "/",
"AgentType": ["OAuth2Client"],
"com.forgerock.openam.oauth2provider.grantTypes": [
"[0]=authorization_code"
],
"com.forgerock.openam.oauth2provider.scopes": [
"[0]=openid"
],
"com.forgerock.openam.oauth2provider.tokenEndPointAuthMethod": [
"client_secret_basic"
],
"com.forgerock.openam.oauth2provider.redirectionURIs": [
"[0]=http://openidm.example.com:8080/"
],
"isConsentImplied": [
"true"
],
"com.forgerock.openam.oauth2provider.postLogoutRedirectURI": [
"[0]=http://openidm.example.com:8080/",
"[1]=http://openidm.example.com:8080/admin/"
]
}'
Create Relying Party

The OAuth Client should be created.

RP / Client created

Integrate IDM and AM

AM is now configured as an OIDC provider and has an OIDC Relying Party for IDM to use, so now we can configure the final step, that is, tell IDM to outsource authentication to AM.

Feel free to modify and copy this authentication.json file directly into your ~/openidm/samples/full-stack/conf folder or follow these steps to configure.

Browse to Configure, then Authentication.

Configure authentication

Authentication should be configured to Local, select ForgeRock Identity Provider.

Outsource authentication to AM

After you click above, the Configure ForgeRock Identity Provider page will pop up.

Set the appropriate values for

  • Well-Known Endpoint
  • Client ID
  • Client Secret
  • Note that the common datastore is set to the DS shared repository, leave this as is.

You can change the others to match your environment but be careful as the values must match those set in AM OP/RP configuration above. You can also refer to the sample the sample authentication.json. Once completed press Submit. You will be asked to re-authenticate.

IDM authentication settings

Testing the integrated environment

Everything is now configured so we are ready to test end to end.

Test End User UI

Browse to the IDM End User UI.

http://openidm.example.com:8080/

You will be directed to AM for login, let’s login with the test user we created earlier.

Login as test user

After authentication you will be directed to IDM End User UI welcome page.

Login success

Congratulations you did it!

Test IDM Admin UI

In this test you’ll login to AM as amadmin and IDM will convert this to a session for the IDM administrator openidm-admin.

This is achieved through the following script:

~/openidm/bin/defaults/script/auth/amSessionCheck.js

Specifically this code snippet is used:

if (security.authenticationId.toLowerCase() === "amadmin") {
security.authorization = {
"id" : "openidm-admin",
"component" : "internal/user",
"roles" : ["internal/role/openidm-admin", "internal/role/openidm-authorized"],
"moduleId" : security.authorization.moduleId
};

In a live environment you should not use amadmin, or openidm-admin but create your own delegated administrators, however in this case we will stick with the sample.

Browse to the IDM Admin UI.

http://openidm.example.com:8080/admin/

You will be directed to AM for login, login with amadmin.

Login as administrator

After authentication you will be directed to IDM End User UI welcome page.

Note: This may seem strange as you requested the Admin UI but it is expected as the redirection URI is set to this page (don’t change this as you can just browse to admin URL after authentication).

Login success

On the top right click the drop down and select Admin, or alternatively just hit the IDM Admin UI URL again.

Switch to Admin UI

You’ll now be directed to the Admin UI and as an IDM administrator you should be able to browse around as expected.

IDM Admin UI success

Congratulations you did it!

Finished.

References

  1. https://backstage.forgerock.com/docs/idm/6.5/samples-guide/#chap-full-stack
  2. khttps://forum.forgerock.com/2018/05/forgerock-identity-platform-version-6-integrating-idm-ds/
  3. https://forum.forgerock.com/2016/02/forgerock-full-stack-configuration/

This blog post was first published @ https://medium.com/@marknienaber included here with permission.

Enhancing User Privacy with OpenID Connect Pairwise Identifiers

This is a quick post to describe how to set up Pairwise subject hashing, when issuing OpenID Connect id_tokens that require the users sub= claim to be pseudonymous.  The main use case for this approach, is to prevent clients or resource servers, from being able to track user activity and correlate the same subject’s activity across different applications.

OpenID Connect basically provides two subject identifier types: public or pairwise.  With public, the sub= claim is simply the user id or equivalent for the user.  This creates a flow something like the below:

Typical “public” subject identifier OIDC flow

This is just a typical authorization_code flow – end result is the id_token payload.  The sub= claim is simply clear and readable.  This allows the possibility of correlating all of sub=jdoe activity.

So, what if you want a bit more privacy within your ecosystem?  Well here comes the Pairwise Subject Identifier type.  This allows each client to be basically issued with a non-reversible hash of the sub= claim, preventing correlation.

To configure in ForgeRock Access Management, alter the OIDC provider settings.  On the advanced tab, simply add pairwise as a subject type.

Enabling Pairwise on the provider

 

Next alter the salt for the hash, also on the provider settings advanced tab.

Add a salt for the hash

 

Each client profile, then needs either a request_uri setting or a sector_identifier_uri.  Basically akin to the redirect_uri whitelist.  This is just a mechanism to identify client requests.  On the client profile, add in the necessary sector identifier and change the subject identifier to be “pairwise”.  This is on the client profile Advanced tab.

Client profile settings

Once done, just slightly alter the incoming authorization_code generation request to looking something like this:

/openam/oauth2/authorize?response_type=code
&save_consent=0
&decision=Allow
&scope=openid
&client_id=OIDCClient
&redirect_uri=http://app.example.com:8080
&sector_identifier_uri=http://app.example.com:8080
Note the addition of the sector_identifier_uri parameter.  Once you’ve exchanged the authorization_code for an access_token, take a peak inside the associated id_token.  This now contains an opaque sub= claim:
{
  "at_hash": "numADlVL3JIuH2Za4X-G6Q",
  "sub": "lj9/l6hzaqtrO2BwjYvu3NLXKHq46SdorqSgHAUaVws=",
  "auditTrackingId": "f8ca531a-61dd-4372-aece-96d0cea21c21-152094",
  "iss": "http://openam.example.com:8080/openam/oauth2",
  "tokenName": "id_token",
  "aud": "OIDCClient",
  "c_hash": "Pr1RhcSUUDTZUGdOTLsTUQ",
  "org.forgerock.openidconnect.ops": "SJNTKWStNsCH4Zci8nW-CHk69ro",
  "azp": "OIDCClient",
  "auth_time": 1517485644000,
  "realm": "/",
  "exp": 1517489256,
  "tokenType": "JWTToken",
  "iat": 1517485656

}
The overall flow would now look something like this:
OIDC flow with Pairwise

This blog post was first published @ http://www.theidentitycookbook.com/, included here with permission from the author.

Step up authentication OpenID Connect

A common use case in access management is step up authentication. ForgeRock AM is very good for that. The OIDC standard talks about step up authentication and level of authentication requested by the client.

To do so, one could use acr_values which is a voluntary claim, but the openid specification says : «  the Authorization Server is not required to provide this Claim in its response. »
In order to achieve that, the essential claim acr is used, it is describe in chapter 5.5.1.1. Requesting the “acr” Claim of the OpenID Core (see: http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics)

In order to demonstrate the functionality, use the following example based on AM 5.1:

In the AM console, browse to Realms >Realm Name>Services, and then click OAuth2 Provider.
Configure the mapping between acr values (in the example 1=ldapService and 2=HOTP chain) in the authorization request and AM authentication chains.

 

OAuth 2 Provider service configuration

HOTP chain contains HOTP module only

Step 1:
The url decoded value of the claims parameter:

{
    “id_token”: 
        {
            “acr”:
                {    
                    “essential”: true, 
                    “values”:[“1”]
                }
        }
}

Click on the URL
http://openam.example.com:8080/openam/oauth2/authorize?response_type=code&scope=openid%20profile&client_id=myClientID&redirect_uri=http%3A%2F%2Fopenam.example.com%3A8080%2Fopenid%2Fcb-basic.html&claims=%7B%22id_token%22%3A%20%7B%22acr%22%3A%7B%22essential%22%3A%20true%2C%20%22values%22%3A%5B%221%22%5D%7D%7D%7D

The user enters the login / password

The id tokens returns acr=1

Step 2:

The url decoded value of the claims parameter:
{
    “id_token”: 
        {
            “acr”:
                {    
                    “essential”: true, 
                    “values”:[“2”]
                }
        }
}

Click on the URL:
http://openam.example.com:8080/openam/oauth2/authorize?response_type=code&scope=openid%20profile&client_id=myClientID&redirect_uri=http%3A%2F%2Fopenam.example.com%3A8080%2Fopenid%2Fcb-basic.html&claims=%7B%22id_token%22%3A%20%7B%22acr%22%3A%7B%22essential%22%3A%20true%2C%20%22values%22%3A%5B%222%22%5D%7D%7D%7D

The user receives OTP and enters the OTP in the login screen.

The id tokens returns acr=2

Note that this is a real step up authentication, the session is alive from step 1 to step 2, the OTP is sent to the user connected at the first step.

 

FranceConnect authentication and registration in ForgeRock AM 5

FranceConnect is the French national Identity Provider (IDP). This IDP acts as a hub that is connected to third party IDPs: La Poste (Mail service), Ameli (Health agency) , impots.gouv.fr (Tax service). National IDP is not a new concept in Europe where the eIDAS regulation applied for years, for example Fedict in Belgium or gov.uk in UK. Whereas the National IDPs are mostly SAML based (some of them uses the Stork profile) the FranceConnect service is OpenID Connect based.

ForgeRock is a FranceConnect partner.

This article explains the FranceConnect implementation in ForgeRock Access Manager 5.0

First creates an account on FranceConnect here https://partenaires.franceconnect.gouv.fr/monprojet/inscription, it takes few minutes.

The only information needed is the callback URL, for example: http://openam.example.com/openam/oauth2c/OAuthProxy.jsp

The clientID « key » and the client secret « secret » will be sent by email.

Then the configuration is done in the admin console of the ForgeRock AM.

Go to Authentication>Modules and create a new OAuth 2.0 / OpenID Connect authentication module.

This configuration maps the user using the email attribute, automatically creates the user in the datastore (optional).

The following attributes have been mapped: given_name=givenname family_name=sn email=mail. The full FranceConnect attribute list is here: https://partenaires.franceconnect.gouv.fr/fournisseur-service

Go to Authentication>Chains and create a new authentication chain FranceConnectNationalAuthenticationService which contains the FranceConnect authentication module as required.

In order to activate the FranceConnect button add it in Services>Social Authentication Implementations.

Lets try!

Go to the login page.

Choose « s’identifier avec FranceConnect »

Example account are provided for major IDP.

Choose the Ameli.fr IDP; example account is login : 18712345678912345 and password :123

The account is stored in the AM datastore.

You are now logged in with Mr Eric Mercier!

Agentless Cross Domain Single Sign-on with Session Upgrade

The following wiki link details a ForgeRock configuration that demonstrates how to achieve cross-domain single sign-on with session upgrade, using OpenID Connect.

Business Case: One of the primary tenants of achieving customer facing omni-channel business presence, is to balance security with reduction of friction. As part of that overall goal, this paper describes a particular set of configuration options that enable the tracking of a user’s actions throughout session in order to enforce security and provide context aware services. This is achieved in an adaptive fashion that reduces friction by not forcing a user to authenticate until absolutely needed. This model does however enable capabilities that provide incentive for suggestive authentication, in order to have richer experience.

Technical Constraint: This particular solution is rather trivial when leveraging the included OpenAM abstraction components either (OpenIG or Policy agents). However due to a recent customer request, this paper describes a deployment approach in a fashion that maximized the developer involvement rather than abstract away from developers the complexity. From a business perspective, this may be the less attractive of a deployment approach, however after describing the more complex case, makes the ideal option easier to understand. So, this solution architecture will have a technical constraint that it must not rely upon proxy or agent-based components; rather, the clients directly engage over modern open standards such as OpenID Connect.
Use-Case: Cross-Cookie-Domain Single Sign-on with support of notion of some resources may require authenticated user, while other resources may consider anonymous as an acceptable status from the centralized access management system. Once authenticated however, other resources should be notified that user has upgraded from anonymous to authenticated user.

 

 

For more info see:  https://wikis.forgerock.org/confluence/display/openam/Agentless+Cross+Domain+Single+Sign-on+with+Session+Upgrade

ForgeRock OpenID Connect Quick Start

After several attempts at a very simple client for OpenID Connect, this wiki entry details my latest example of a simple HTML example of a client to talk to OpenID Connect.  The entire example is a get up an running quick with OpenID Connect with OpenAM and this simple client.

For more see here:  https://wikis.forgerock.org/confluence/display/openam/OpenID+Connect+Quick+Start

This blog post was first published @ http://nin9tyni9e.blogspot.no/, included here with permission from the author.

Scripted OpenID Connect Claims and Custom JWT Contents

This blog post was first published @ identityrelationshipmanagement.blogspot.co.uk, included here with permission.

OpenID Connect has been the cool cat on the JSON authorization cat walk for some time.  A powerful extension to the basic authorization flows in OAuth2, by adding in an id_token. The id_token is a JWT (JSON Web Token, pronounced ‘jot’ but you knew that) that is cryptographically signed and sometimes encrypted – depending on the contents.

The id_token is basically separate to the traditional access_token, containing details such as which authorization issued the token, when the user or entity authenticated and when the token will expire.

OpenAM has supported implementations for OpenID Connect for a while, but a more recent feature is the ability to add scripting support to the returnable claims.  Adding scripting here, is a really powerful feature.  Scripts can be either Groovy or JavaScript based, with a default Groovy script coming with OpenAM 13 out of the box.

The script is basically allowing us to creatively map scopes into attribute data, either held on the user’s identity profile, or perhaps dynamically created at run time via call outs or via applied logic.

A quick edit of the of the out of the box OIDC claims script, allows me to add a users status from their profile held in OpenDJ, into the data available to presented scopes.  I’ve used the inetuserstatus attribute simply as it’s populated by design.  By adding “status” to the scopes list on my OIDC client profile, allows it to be called and then mapped via the script.

So pretty simply I can add in what is made available from the user’s identity profile, which could include permissions attributes or group data for example.

Another neat feature (which isn’t necessarily part of the OIDC spec), is the ability to add claims data directly into the id_token – instead of making the extra hop to the user_info endpoint with the returned access_token.  This is useful for scenarios where “offline” token introspection is needed, where an application, API, device or service, wants to perform local authorization decision making, by simply using the information provided in the id_token.  This could be quite common in the IoT world.

To add the claims data into the signed JWT id_token, you need to edit the global OIDC provider settings (Configuration | Global | OAuth2 Provider).  Under this tab, use the check box “Always return claims in ID Tokens

Now, when I perform a standard request to the ../access_token endpoint, including my openid scope along with my scripted scope, I receive an id_token and access_token combination the same as normal.

 

So I can either call the ../user_info endpoint directly, with my access_token to check my scope values (including my newly added status one) or use a tool or piece of code to introspect my id_token.  The JWT.io website is a quite a cool tool to introspect the id_token by doing the decode and signing verification automatically online.  The resulting id_token introspect would look something like this:
Note the newly added “status” attribute is in the verified id_token.

Introduction to OpenIG (Part 1: Use cases)

Welcome

You've probably landed here because you want to know something about OpenIG. This is the right place to be :)

This post is the first one of a serie of OpenIG-related articles that would gives you hand-on samples with explanations.

Identity Gateway

OpenIG stands for Open Identity Gateway, it is an identity/security specialized reverse proxy. That means that it control the access to a set of internal services.

By controling the access, I mean that it intercepts all the requests coming to the protected service (be it a RESTful API or a web application) and process them before (and after) forwarding them to the server.

Different kind of processing can be handled:

  • Request authorization
  • Capture and password replay
  • Message logging
  • Transformation

Commons use cases

Ok, that was a bit of a generalist description (transformation is intentionally vague :) ). Having some real-life use cases will help to have a better feeling/understanding of what OpenIG is capable of.

SAML Application Federation

In this use case, OpenIG acts as a SAML-enabled facade to a somehow legacy application that cannot be adapted to support SAML federation. The Identity Provider (could be OpenAM) will consider OpenIG as a standard SAML Service Provider.

SAML CoT with OpenIG used as a facade to a legacy application

Application Authentication

Here, OpenIG acts as an OpenID Connect Relying Party (OIDC terminology for client) and requires the user to authenticate to an OpenID Connect Provider (the identity provider) before giving him/her access to the protected application.

Authenticated user's profile information (such as name, email, address, picture, ...) are available to enrich the user experience, or make further verifications.

OpenID Connect - OpenIG Relying Party

RESTful Services Protection

This simple case shows OpenIG verifying request to a proxified RESTful API: each request must contains a valid OAuth 2.0 Bearer Token to be allowed to reach the service API. In this case, OpenIG acts as an OAuth 2.0 Resource Server.

Very useful if you have an old-fashioned REST API that you cannot easily update to deal with OAuth 2.0 tokens.

OAuth 2.0 - OpenIG ResourceServer

Not enough ?

Well, we're done with the 'marketing' stuff. In the next post, we will start to play with OpenIG.

See you soon!

The Evolution of Identity & Access Management

Identity and access management is going through a renaissance.  Organisations, both public and private have spent thousands of hours (and dollars) implementing and managing infrastructure that can manage the creation of identity information, as well as management of the authentication and authorization tasks associated with those identities.  Many organisations do this stuff, because they have to.  They're too large to perform these tasks manually, or perhaps have external regulations that require that they have a handle on the users who access their key systems. But how and why is all this changing?



The Enterprise and The Perimeter

Changing Identities
15 years ago, identity and access management was focused on stuff that happened within the corporate firewall.  Employees joined the company, were entered into the payroll system and 'IT' set them up on the necessary systems they needed.  That setup process was often manual, inconsistent and perhaps involved several different application and system owners and administrators.  IT being IT, would look to try and automate that account creation process.  This was driven partly by business benefits (new employees don't need to wait 3 days for to get working) and also the costs savings associated with migrating manual tasks to a centralised provisioning system.


Cloud, Services & The Modern Enterprise

Organisations are not the same as they were 15 years.  I talked about this recently with the onset of the 'modern' enterprise.  What does that mean?  Due to economic changes and changes in working patterns,  organisations are now multifaceted complex beasts.  No one team or department can be associated with a single process or business function.  Supply chains are now swollen by outsourced providers, all rapidly engaged and critical to short term product launches or business deliverables.  These business changes rely heavily on an agile identity management and authentication infrastructure, that can not only quickly engage new partners or suppliers, but also track, authorize, audit and remove users when they are no longer required or a partner contract expires.

Continually Connected

Identity from a consumer sense has also altered.  More and more individuals have an identity context on line.  That could be something like a Facebook or LinkedIn account, right through to personal email, banking and ecommerce as well as consumer outsourced services such as Spotify, Kindle books or iTunes.  Individuals are embracing applications and services that can give them non-physical access to experiences or data stores, all centred about their own identity.  These online consumer identities are only as valid of course, if the identity owner is able to connect to those services and sites.  That connectivity is now ubiquitous, making life experiences richer, whilst increasing demands for consumer scale infrastructure.

Standards and More Standards

I recently watched the Gartner on demand catch up series of the recent Catalyst event, that was neatly titled the "Identity Standards Smackdown".  A panel of 5 leading identity go-getters, represented some of the emerging and long standing IAM standards, promoting their worth in the current landscape.  The five represented were OAuth2, SCIM, XACML, OpenID Connect and SAML2.  The details of each are all varied and there are numerous pro's and con's to each.  What is interesting, is that we are now at a position where all of these standards are now playing a part in both public and private enterprise adoption, acting as catalysts for new service offerings by services and software vendors, as well as acting as a yardstick to aid comparisons, maturity metrics, interoperability and more.

The standards all play slightly different parts in the provisioning, authentication and authorization life cycle, but the healthy debate goes to show the both end user and vendor interest in this space is as hot as it has even been.

By Simon Moffatt

The Evolution of Identity & Access Management

Identity and access management is going through a renaissance.  Organisations, both public and private have spent thousands of hours (and dollars) implementing and managing infrastructure that can manage the creation of identity information, as well as management of the authentication and authorization tasks associated with those identities.  Many organisations do this stuff, because they have to.  They're too large to perform these tasks manually, or perhaps have external regulations that require that they have a handle on the users who access their key systems. But how and why is all this changing?



The Enterprise and The Perimeter

Changing Identities
15 years ago, identity and access management was focused on stuff that happened within the corporate firewall.  Employees joined the company, were entered into the payroll system and 'IT' set them up on the necessary systems they needed.  That setup process was often manual, inconsistent and perhaps involved several different application and system owners and administrators.  IT being IT, would look to try and automate that account creation process.  This was driven partly by business benefits (new employees don't need to wait 3 days for to get working) and also the costs savings associated with migrating manual tasks to a centralised provisioning system.


Cloud, Services & The Modern Enterprise

Organisations are not the same as they were 15 years.  I talked about this recently with the onset of the 'modern' enterprise.  What does that mean?  Due to economic changes and changes in working patterns,  organisations are now multifaceted complex beasts.  No one team or department can be associated with a single process or business function.  Supply chains are now swollen by outsourced providers, all rapidly engaged and critical to short term product launches or business deliverables.  These business changes rely heavily on an agile identity management and authentication infrastructure, that can not only quickly engage new partners or suppliers, but also track, authorize, audit and remove users when they are no longer required or a partner contract expires.

Continually Connected

Identity from a consumer sense has also altered.  More and more individuals have an identity context on line.  That could be something like a Facebook or LinkedIn account, right through to personal email, banking and ecommerce as well as consumer outsourced services such as Spotify, Kindle books or iTunes.  Individuals are embracing applications and services that can give them non-physical access to experiences or data stores, all centred about their own identity.  These online consumer identities are only as valid of course, if the identity owner is able to connect to those services and sites.  That connectivity is now ubiquitous, making life experiences richer, whilst increasing demands for consumer scale infrastructure.

Standards and More Standards

I recently watched the Gartner on demand catch up series of the recent Catalyst event, that was neatly titled the "Identity Standards Smackdown".  A panel of 5 leading identity go-getters, represented some of the emerging and long standing IAM standards, promoting their worth in the current landscape.  The five represented were OAuth2, SCIM, XACML, OpenID Connect and SAML2.  The details of each are all varied and there are numerous pro's and con's to each.  What is interesting, is that we are now at a position where all of these standards are now playing a part in both public and private enterprise adoption, acting as catalysts for new service offerings by services and software vendors, as well as acting as a yardstick to aid comparisons, maturity metrics, interoperability and more.

The standards all play slightly different parts in the provisioning, authentication and authorization life cycle, but the healthy debate goes to show the both end user and vendor interest in this space is as hot as it has even been.

By Simon Moffatt