If you ever seen a security report for one of your web applications, there is a good chance that you have seen a big warning about Clickjacking already. Clickjacking is a certain kind of attack that essentially allows the attacker to trick a victim into performing an operation that most likely they didn’t want to carry out. If you want to learn more about clickjacking then I would recommend having a read of this well detailed page.

The best way to protect against these attacks is actually rather simple: RFC 7034 describes the X-Frame-Options header that needs to be set on the HTTP responses for pages that you wish to prevent from being clickjacked. The X-Frame-Options header has three accepted values:

• DENY: the browser should never display the contents of the requested content in a frame.
• SAMEORIGIN: Only display the content in a frame, if the enclosing page(/top level browsing context — see RFC) is in the same origin as the content itself.
• ALLOW-FROM: Allows you to specify an origin from which it is allowed to display the contents of the requested resource.

How to configure OpenAM?

Since OpenAM 12.0.1 it is possible to utilize a built-in servlet filter to add arbitrary HTTP headers to our responses. The configuration of the filter is quite simple, you just have to add the following snippets to web.xml (obeying the XML schema):

<filter>
  <filter-name>Clickjacking</filter-name>
  <filter-class>org.forgerock.openam.headers.SetHeadersFilter</filter-class>
  <init-param>
    <param-name>X-Frame-Options</param-name>
    <param-value>DENY</param-value>
  </init-param>
</filter>
...
<filter-mapping>
  <filter-name>Clickjacking</filter-name>
  <url-pattern>/XUI/*</url-pattern>
  <url-pattern>/UI/*</url-pattern>
  <url-pattern>/console/*</url-pattern>
  <url-pattern>/oauth2/authorize</url-pattern>
  <dispatcher>FORWARD</dispatcher>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>INCLUDE</dispatcher>
  <dispatcher>ERROR</dispatcher>
</filter-mapping>

The above url-patterns list is not an exhaustive list of resources that you may wish to protect, however it should serve as a good start. Alternatively you could just change the url-pattern to /* and then you only really need the REQUEST dispatcher in your filter mapping config.

Please keep in mind that there are lots of different ways to set the X-Frame-Options header for your deployment, so feel free to utilize those instead if needed.

This blog post was first published @ http://blogs.forgerock.org/petermajor/, included here with permission.

OpenAM JavaScript Wrapper

A long time ago I started writing an example of a small web application that was using the OpenAM REST APIs. Once working on this task, I realised it was relatively easy to create wrappers around the ForgeRock APIs in any programming language. I decided to start with a JavaScript wrapper.

I am a bit rusted in this area, and since I was doing it only for fun and on my “idle” time, it took a while.  Anyway, here the openam.js wrapper and the openamUtils.js utility library. https://github.com/ForgeRock/openamjs

This is a work in progress, and also a JavaScript coding exercise. Initially it is leveraging the Authentication and SSO API’s but with a little help of the community it can be extended to cover the whole set of APIs, inclulding Authorization, OAuth2, OIDC, UMA, STS, etc. It can also be an idea to start similar wrappers for the OpenIDM and OpenDJ REST APIs. It is NOT supported NOR endorsed by ForgeRock. If you feel it is useful, please contribute.

openam.js is a small library/wrapper of some of the REST APIs of OpenAM. The intention is to provide an easy way to integrate the calls in your Client JavaScript code without needing to implement the REST code yourself.

openamUtils.js is another wrapper to render configurable Login Buttons and Login Boxes. It uses openam.js and the css style contained in the github repository, of course you can adjust the css to your needs but it should work nicely out of the box. This wrapper does not need JQuery, but of course you can combine it with any other JS UI framework. In the future I would like to create another library combined with bootstrap.

Several examples are included together with the source code: https://github.com/ForgeRock/openamjs/tree/master/examples

Each example is a single web page.

Before trying the library and examples be sure to configure your OpenAM to support CORS (see this blog entry for more info on CORS and OpenAM, hint it involves to modify the web.xml of OpenAM or modify your Web Container -Tomcat for example has CORS support-).

The documentation is available for both libraries here:

• OpenAMJS Documentation
• OpenAMUtils Documentation

  Here two videos showing how to use the libraries.

  1. OpenAM Configuration of the instance to be used with the examples.
      
     

      

      

  2. And here a video showing how the examples included in the github code work:

      

   

  Give the libraries a try and send us your feedback. Again you are more than welcome to contribute.

If you’ve used OpenAM for a while, you will probably know that it has a concept of shared state; a map of values that can be passed from one authentication module to the next in an authentication chain. You can use the iplanet-am-auth-store-shared-state-enabled and iplanet-am-auth-shared-state-enabled keywords to direct modules to put credentials into shared state, or read the credentials from shared state and try to use them.

If you have a scripted module in your OpenAM authentication chain,  you may want to pass credentials from the scripted module to other modules in the chain. Or you may want to access credentials that have been set in a preceding authentication module.

To read the username and password entered in a previous module in the authentication chain, you can use the following javascript in your server side authentication script:

//get username and password from shared state var someUserName = sharedState.get("javax.security.auth.login.name"); var somePassword = sharedState.get("javax.security.auth.login.password");

And to put a username and password into shared state:
//set the username and password for other authentication modules to use sharedState.put("javax.security.auth.login.password",someUserName); sharedState.put("javax.security.auth.login.password",somePassword);

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

Authentication Chains

We have not talked much about OpenAM on the blog. AM has some really great features that make it very simple to use. Perhaps my favourite feature is the authentication chains UI.

Let’s take a quick look at what an authentication chain looks like, then we will talk through it and have a go at creating a brand new one. I assume you are using OpenAM 13.

You can see what an auth chain looks like above. Essentially it is a series of steps ( I think of them as Lego like building blocks ) for authentication. Each block represents a different mechanism for authenticating. In addition each block is also assigned one of four authentication behaviors (required, optional, requisite & sufficient) which determine how ( and if ) one block flows into the next depending whether that block succeeds.

As stated above, successful authentication required at least one pass and no fail flags.

In the above example there are four blocks, lets look at each in turn:

• DataStore: Basic username and password authentication against the OpenAM data store. If this step is a:
  • FAIL: The user hasn’t even got their username and password right. We definitely are not letting them in, and as such exit the chain with a FAIL.
  • PASS: The username and password is correct. We move to the next block in the chain DeviceMatch.
• DeviceMatch: First step of device match authentication ( essentially asking the question: has OpenAM seen the use log in from this device before? ). If this step is a:
  • CONTINUE: OpenAM has not seen the user log in using this particular laptop or mobile before. This block has failed but, because it is sufficient this does not equate to a fail flag. We have to be a bit more suspicious and go into the TwoFactor block.
  • PASS: This is a device the user has used before and OpenAM recognises it. At this point the user has authenticated with username and password from a recognised device. We exit the chain with a PASS. 
• TwoFactor: Challenge the user to provide the code from a two factor mobile soft token. This second factor proves that not only does the user have the right username and password, but also that they have the mobile device they originally registered with in their possession. If this step is a:
  • FAIL: The user has failed 2FA. At this point we don’t have the confidence this is really the user being claimed and exit with a FAIL.
  • PASS:
• DeviceSave: The last step of device match authentication. We save a record of the device so we can match it next time in the DeviceMatch step. If this step is a fail:
  • FAIL: The user is not actually being challenge for anything. Authentication is complete. We just need to save the device which will not fail.
  • PASS: We have now saved the device, in future, so long as the user continues to use this particular laptop or mobile to login. They will not have to do the TwoFactor step.

Note that I have chosen the above authentication “blocks” for this particular blog. I could easily have used others. There are many different types of blocks available in OpenAM covering nearly every conceivable authentication requirement.

I think the way OpenAM allows you to quickly use these building blocks to build authentication visually is really neat.

Let’s now try building the above chain in OpenAM.

Building an Authentication Chain

Testing the Authentication Chain

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

I’m excited to introduce a new podcast series hosted by Daniel Raskin and myself. The series will focus on (what we hope are!) interesting identity topics, news about ForgeRock, events, and much more. Take a listen to the debut episode below where we discuss why and how to get rid of passwords, how stateless OAuth2 tokens work, and some current events, too!

-Chris

I recently had cause to play with ‘Dynamic Profiles’ in OpenAMv13.

If you don’t know then Dynamic Profile is a realm based configuration setting that can dynamically create a user profile in the configured DataStore.  This can be useful in many circumstances where the authentication of a user takes place in a service other than the DataStore.  Examples of this include using OpenAM as Social Media/Oauth2 client (allowing users to sign in with Facebook), and SAML Service Provider (e.g. allowing users to sign in with Federated credentials).  Having authenticated the credentials it now might be useful to maintain a profile of that user that is used throughout their interactions with the services protected by OpenAM.

The specific scenario that triggered this investigation (and therefore this blog post!) was one where the user is authenticated by credentials in an Active Directory, but the user profile (DataStore) was a separate OpenDJ instance.

Now before I go any further it is entirely possible to make the AD your DataStore making things simple.  However, there are many occasions where the schema changes needed in a directory to provide the full range of DataStore capabilities are simply not allowed to be applied to an Active Directory due to business or security policy.  Therefore it is necessary to configure a separate DataStore using, say, OpenDJ as well as allow users to authenticate against AD with their AD credentials.

By default OpenAM configures a realm to ‘Require’ a profile entry in the DataStore for an authenticated user.  Therefore a user profile has to exist in the DataStore in order for authentication to complete.

Now you could provision a set of user profiles into the DataStore using something like OpenIDM to ensure the required profile exists.  Or you can set ‘Dynamic’ profiles in OpenAM.  This causes OpenAM to dynamically create a profile in the configured DataStore if one does not exist.
So, if we’re ‘dynamically’ creating profiles, what data does OpenAM use to populate the DataStore?   Good question…and one that this post is designed to answer!

First, the basics…

• Authentication Chain
  As described we want the user to authenticate using their AD credentials.  Therefore we need to define the Authentication Chain to contain an LDAP Authentication Module (or the AD module if you prefer).  Let’s assume you can get this working (you may choose to set profile as ‘Ignored’ whilst you set this up so that authentication can complete without the need for a profile at all).

• DataStore
  We’ll be using OpenDJ as the DataStore.  Let’s assume you can setup OpenDJ and configure it as a DataStore.  The OpenAM documentation on Backstage provides guidance on this.

Ok, so now we need to tie these together.  The general idea is that a user logs in with their AD credentials using the Authentication Chain/Module.  OpenAM checks to see if there is an associated user profile record in the DataStore and creates it if not.

Let’s first of all consider the Authentication Module.  There are two key properties here:

1. Attribute Used to Retrieve User Profile
2. User Creation Attributes

Attribute Used to Retrieve User Profile

In my experience the description and helptext for this is not entirely accurate.  In the scenario I’m describing, OpenAM will retrieve the value of this attribute from the AD/LDAP.  It will then be placed into memory for use later on.  Let’s call this ‘AttributeX’.  Typically the attribute you want to retrieve is the unique identifier for the user, so might be sAMAccountName or uid, for example.  We’ll use the value in ‘AttributeX’ later when we search for and find the user profile in the DataStore.

User Creation Attributes

This is a list of attribute values to be retrieved from the AD/LDAP authentication source that we wish to pass through to the user profile creation step.
You can specify these attributes either as singletons such as ‘sn’ or ‘mail’.  Or as pipe separated maps such as phoneNum|telephoneNumber.
Again the description of the pipe mapping syntax is confusing.
In actual fact it should be read as:
OpenAM property|AD/LDAP property
i.e. the setting of phoneNum|telephoneNumber would take the value of telephoneNumber from AD/LDAP and store it in an OpenAM property called phoneNum.  We can then use the OpenAM property later when we create the record in the DataStore.
Note that the singleton syntax such as ‘sn’ will essentially be interpreted as ‘sn|sn’.
Also note that the list that appears here is explicit.  If a property is not in this list then the DataStore will not be able to access it during creation.

Ok, so now we know how to extract information from the AD/LDAP that we authenticate against and store it in OpenAM properties.  Now let’s look at the DataStore configuration.

There are a couple of things to look at here, but they’re mostly in the ‘User Configuration’ section:
1. LDAP Users Search Attribute
2. LDAP People Container Naming Attribute
3. LDAP People Container Value
4. Create User Attribute Mapping
and, in the Authentication Configuration section,
5. Authentication Naming Attribute

LDAP Users Search Attribute

This is the attribute that will contain the value of ‘AttributeX’ i.e. the unique key for the user.  Typically in OpenDJ this is often ‘uid’, but could be something else depending on your configuration.  For example I want a DN of a person record to be something like:
cn=<userid>,cn=users,dc=example,dc=com
whereas the default might be:
uid=<userid>,ou=people,dc=example,dc=com
Therefore I need the search attribute to be ‘cn’ not ‘uid’.

LDAP People Container Naming Attribute

As you can see from my desired DN, the container for the ‘people’ records is ‘users’ named by the ‘cn’ property.  Hence the value I specify here is ‘cn’.  The default (for OpenDJ) is ‘ou’ here.

LDAP People Container Value

Again, from the desired DN you can see that I needs to specify ‘users’ here, whereas the the default is ‘people’.

These settings are used to both find a user as well as set the DN when the user is dynamically created.
So, with my settings a user will be created thus:
cn=<userid>,cn=users,dc=example,dc=com

(The dc=example,dc=com section is defined as the ‘LDAP Organization DN’ elsewhere in the DataStore config but you should already have that setup correctly!)

Create User Attribute Mapping

Now this is the interesting bit!  This is where the values we retrieved from the AD/LDAP Authentication module and placed in to OpenAM properties can be mapped to attributes in the DataStore.
By default the list contains two singletons: cn and sn

But the helptext says you must specify the list as ‘TargetAttributeName=SourceAttributeName’ which the defaults don’t follow.
Remember that ‘AttributeX’ we collected?  Well any singleton attribute in this list will take the value of AttributeX…if it was not explicitly defined in the Authentication Module ‘User Creation Attributes’ map.
i.e. if User Creation Attributes included ‘sn’ then the value of that would be used for the ‘sn’ value here.  If there was no mapping then ‘sn’ here would take the value of AttributeX.

This particular nuance allows you to configure a setting to ensure that attributes that are defined as ‘mandatory’ in the DataStore to always have an attribute value.  This avoids record creation errors due to missing data constraints defined in the DataStore.

Now, what happens if we use the ‘TargetAttributeName=SourceAttributeName’ format?  Well, in this case ‘TargetAttributeName’ refers to the name of the attribute in the DataStore, whereas ‘SourceAttributeName’ refers to the OpenAM property as specified in Create User Attribute Mapping of the Authentication Module.

Oh, and there’s one extra consideration here…
If the OpenAM property name (as defined in Create User Attribute Mapping) exactly matches the name of a DataStore property then you don’t need to specify it at all in this list!!

For example, say you want to take the value of ‘givenName’ from the AD/LDAP and place it in the attribute called givenName in the DataStore then all you need to do is specify ‘givenName’ in the Authentication Module Create User Attribute Mapping settings.  There is no need to explicitly define it in this list.

However, if you do define it in this list then you must define it as givenName=givenName.
If you were to just specify givenName then it’s value will be that of the mysterious ‘AttributeX’.

and finally…

Authentication Naming Attribute

For my configuration I set this to ‘cn’.  This is a bit of conjecture, but I believe this configuration is used when the DataStore Authentication Module is used.  The DataStore Authn Module will take the username entered by the user on the login page and try to find a user record where the ‘cn’ equals it.
Now in my scenario this should never happen…I never intend the DataStore to be used as an authentication source…but, as they say, YMMV.

This blog post was first published @ yaunap.blogspot.no, included here with permission from the author.