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