Meta

Month: December 2015

This blog post was first published @ www.fedji.com, included here with permission.

ForgeRock OpenIDM, the Identity Management solution from ForgeRock offers nice and easy way to perform most of the common scenarios one can think of in the Identity Management domain. Once such commonly occurring situations is to link an account of a User in IDM with his/her Multiple accounts in a resource such as LDAP Server such as ForgeRock OpenDJ. Let’s try to understand how that’s achieved in OpenIDM using the illustration below:

As you can make out, OpenIDM is connected to an OpenDJ instance. You could also see two OpenIDM Roles defined namely ‘Agent’ and ‘Insurer’. Each of the Role is attached to a Managed Assignment. And the Managed Assignment in turn has Attributes and Link Qualifiers. The Attribute refers to a User Attribute in OpenDJ with a corresponding value (say cn=Chat Users, ou=Groups,dc=example,dc=com) and Link Qualifier is used to construct a DN (say uid=bjensen,ou=Customers,dc=example,dc=com).

So a Role that has the Managed Assignments with the said Attributes and Link Qualifier would (i) be a member of ‘cn=Chat Users, ou=Groups,dc=example,dc=com‘ and will belong to a branch that’s determined by the DN ‘uid=bjensen,ou=Customers,dc=example,dc=com‘. Clearly, multiple OpenIDM Role assignments to a single OpenIDM User will link that User’s account with multiple DNs in the OpenDJ instance. Please note that the LDAP group is omitted from the illustration above for brevity. The following equation might give us a rough translation of the statements as mentioned above:

OpenIDM User (bjensen) OpenIDM Role (Insurer) Managed Assignment (cn=Chat Users,ou=Groups,dc=example,dc=com Attribute && dn: uid=?,ou=Customers,dc=example,dc=comLink Qualifier) ===> bjensen user in the ou=Customers branch of OpenDJ instance DIT (uid=bjensen, ou=Customers,dc=example,dc=com) and the user’s subscription to a LDAP Group cn=Chat Users, ou=Groups,dc=example,dc=com)
Not clear? Have a screen-cast for you. Please take a look and see if it gives you a clearer picture.

This blog post was first published @ www.fedji.com, included here with permission.

Merry Christmas!

For those interested to know how to configure Roles in ForgeRock OpenIDM, here’s my Christmas gift. A video at the end of this post will walk you through the installation of both ForgeRock OpenIDM and ForgeRock OpenDJ, configure the latter as an external resource in OpenIDM, performing reconciliation to bring in users from OpenDJ to OpenIDM. That’s not it, because all of that I’ve shown you earlier as well. Then, what’s more? Here it is:

So we go on and create Roles in OpenIDM, which has Managed Assignments that in turn has Attributes associated with an external resource (ForgeRock OpenDJ). So when a Role is assigned to a user in OpenIDM, based on the value of Attribute that is attached to the Role, the user will be subscribed to a group in the OpenDJ. If it sounds confusing,please don’t waste time reading it again, instead watch the video below, it’ll all be crystal clear.

I’ve done a similar screen-cast before, but that’s using OpenIDM 3.x. Be wary of the fact that the software used in this screen-cast is not yet read for Production. But now that the ForgeRock Management have given us this clue on the road ahead for the ForgeRock Products, it makes sense to start exploring it (if not already done).

So in the video below, you’ll see the lightning fast installation of both OpenIDM and OpenDJ and configuration of OpenDJ as an External Resource for OpenIDM.

It's that time of year again, when the retrospective and predictive blogs come out of the closet, just before the Christmas festivities begin. This time last year, the 2015 predictions were an interesting selection of both consumer and enterprise challenges, with a focus on:

Customer Identity Management

The start of IoT security awareness

Reduced Passwords on Mobile

Consumer Privacy

Cloud Single Sign On

In retrospect, a pretty accurate and ongoing list. Consumer related identity (cIAM) is hot on most organisation's lips, and whilst the password hasn't died (and probably never will) there are more people using things like swipe login and finger print authentication than ever before.

But what will 2016 bring?

Mobile Payments to be Default for Consumers2015 has seen the rise in things like Apple Pay and Samsung Pay hitting the consumer high street with venom. Many retail outlets now provide the ability to "tap and pay" using a mobile device, with many banks also offering basic contactless payments on debit cards. The limit for such contactless payments, was recently upped to £30 in September, making the obvious choice for busy interactions such as supermarkets and coffee shops. This increased emphasis on the mobile representing an identity, will put pressure on mobile's ability for secure credential storage and the potential for fraud and payment data theft.

Internet of Things Data Sharing to be TackledIoT is everywhere. The "web of things", the "internet of everything", each week a new term is coined. The simple fact is that millions more devices are coming on line, and are generating, collecting and aggregating data from a range of sources - both personal and machine related. That data needs to be effectively shared using a transparent consent model. Individuals are more accurately aware than ever before, that their data can be used in a myriad of different ways - some for service improvement but some maliciously. 3rd party data sharing is inevitable, if the true benefits of the IoT world are to be realised - but that data sharing requires real consent and revocation capabilities using standards such as User Managed Access and others.EU General Data Protection Regulation Brings New Organisational ChallengesThe recent change in the EU GDPR, will bring challenges for many organisations looking to leverage the power of digital transformation or harness the power of cloud. The new EU changes, provide a clear message, regarding the use and management of user data, with powerful fines now acting as a large incentive for compliance and process redesign. Many end users and consumers are becoming fully aware of how powerful their data can become, when combined with things like tracking, marketing or analytics and full and proper control over that data should be made available.An Increase in Device Pairing & SharingThe increase in house hold and consumer devices with "smart" capabilities is leading to a more "pin and pair" ecosystems for things like smart TVs, connected cars, home heating systems, fridges and more. The ability for a device to be linked to a physical identity, brings a brand new set of use cases for identity impersonation, data sharing and personalisation. The ability for a TV to be linked to a physical person and not just a household for example, brings interesting use cases for personalised content delivery. The pairing of devices will probably leverage existing authorization standards such as OAuth2, where quick and simple revocation will help to increase confidence in how physical identities can be linked and revoked from devices.

Every Company Will Have a Blockchain R&D TeamThe Bitcoin revolution seems to have hit the top of the "peak of inflated expectations", with the effective delivery still some 5 to 10 years away. However, the capabilities of the blockchain architecture are starting to visit new non-currency related use cases, such as intellectual property protection, art copyrighting, access request cataloguing and more. The interest in the distributed and hashed nature of the blockchain, make new transparent data sharing and decision point architectures a potential weapon in the security architect's arsenal. Whilst many of the capabilities and features may need implementing, many organisations will be looking on with keen eyes, to see if this ecosystem can start to deliver on it's early promise.

Will be interesting to see what 2016 brings. One thing is for sure, that information security has never been such a concern for many organisations in both the private and public sector.

It's that time of year again, when the retrospective and predictive blogs come out of the closet, just before the Christmas festivities begin. This time last year, the 2015 predictions were an interesting selection of both consumer and enterprise challenges, with a focus on:

Customer Identity Management

The start of IoT security awareness

Reduced Passwords on Mobile

Consumer Privacy

Cloud Single Sign On

In retrospect, a pretty accurate and ongoing list. Consumer related identity (cIAM) is hot on most organisation's lips, and whilst the password hasn't died (and probably never will) there are more people using things like swipe login and finger print authentication than ever before.

But what will 2016 bring?

Mobile Payments to be Default for Consumers2015 has seen the rise in things like Apple Pay and Samsung Pay hitting the consumer high street with venom. Many retail outlets now provide the ability to "tap and pay" using a mobile device, with many banks also offering basic contactless payments on debit cards. The limit for such contactless payments, was recently upped to £30 in September, making the obvious choice for busy interactions such as supermarkets and coffee shops. This increased emphasis on the mobile representing an identity, will put pressure on mobile's ability for secure credential storage and the potential for fraud and payment data theft.

Internet of Things Data Sharing to be TackledIoT is everywhere. The "web of things", the "internet of everything", each week a new term is coined. The simple fact is that millions more devices are coming on line, and are generating, collecting and aggregating data from a range of sources - both personal and machine related. That data needs to be effectively shared using a transparent consent model. Individuals are more accurately aware than ever before, that their data can be used in a myriad of different ways - some for service improvement but some maliciously. 3rd party data sharing is inevitable, if the true benefits of the IoT world are to be realised - but that data sharing requires real consent and revocation capabilities using standards such as User Managed Access and others.EU General Data Protection Regulation Brings New Organisational ChallengesThe recent change in the EU GDPR, will bring challenges for many organisations looking to leverage the power of digital transformation or harness the power of cloud. The new EU changes, provide a clear message, regarding the use and management of user data, with powerful fines now acting as a large incentive for compliance and process redesign. Many end users and consumers are becoming fully aware of how powerful their data can become, when combined with things like tracking, marketing or analytics and full and proper control over that data should be made available.An Increase in Device Pairing & SharingThe increase in house hold and consumer devices with "smart" capabilities is leading to a more "pin and pair" ecosystems for things like smart TVs, connected cars, home heating systems, fridges and more. The ability for a device to be linked to a physical identity, brings a brand new set of use cases for identity impersonation, data sharing and personalisation. The ability for a TV to be linked to a physical person and not just a household for example, brings interesting use cases for personalised content delivery. The pairing of devices will probably leverage existing authorization standards such as OAuth2, where quick and simple revocation will help to increase confidence in how physical identities can be linked and revoked from devices.

Every Company Will Have a Blockchain R&D TeamThe Bitcoin revolution seems to have hit the top of the "peak of inflated expectations", with the effective delivery still some 5 to 10 years away. However, the capabilities of the blockchain architecture are starting to visit new non-currency related use cases, such as intellectual property protection, art copyrighting, access request cataloguing and more. The interest in the distributed and hashed nature of the blockchain, make new transparent data sharing and decision point architectures a potential weapon in the security architect's arsenal. Whilst many of the capabilities and features may need implementing, many organisations will be looking on with keen eyes, to see if this ecosystem can start to deliver on it's early promise.

Will be interesting to see what 2016 brings. One thing is for sure, that information security has never been such a concern for many organisations in both the private and public sector.

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:

This blog post was first published @ www.fedji.com, included here with permission.

You’ve reached the concluding episode of a four part video made on using SAML v2 Assertion attributes in an application protected by ForgeRock OpenAM. I don’t need to mention that this being the last one in the lot, it may seem pointless to read/view this entry independently without going through the entries below, preferably in the exact same order as is listed:

We can safely say that the diagram below is the end state of our demonstration:

So what we’ve in there is a client attempting to access the protected J2EE Application, which is intercepted by the OpenAM Policy Agent, who in turn redirects the request to an IDP initiated SSO URL, resulting in a Login page to the end user from IDP. The IDP would then validate the credentials supplied by the end user, and if found authentic, sends an assertion to the SP with the user attributes (like mail, telephonenumber) specified in the Federation Configuration. Because it uses Transient Federation, the user will not have a profile in SP, still the attributes in the Assertion is available in the user’s session to be used by the Agent to pass on to the application. It may have sounded complicated, but I’m confident that the concluding episode of a rather lengthy screen-cast can help you figure it all.

I want to take a moment to Thank you! to have spent time reading/viewing my web logs on ‘Using SAML Assertion Attributes’ and sincerely hope it was useful.

This blog post was first published @ www.fedji.com, included here with permission.

This is the third episode from a four part video made on using SAML v2 Assertion attributes in an application protected by ForgeRock OpenAM. In the interest of continuity and also to get the context accurately, it may make sense to read/view the blog posts in the following order:

The diagram is a slightly modified version of the one that you would have seen in my earlier blog entry. It has one additional user in the Identity Provider (which of course seems like a world famous detective and that’s no coincidence), but no corresponding entry in the Service Provider. In the Identity Federation Configuration earlier, we saw how a user with an id ‘demo’ in the Identity Provider linked her account with her id in the Service Provider. But there can be situations, when we may want to use Federation with identities only at the IDP, still gaining access to the applications protected by the SP. That’s where Transient Federation comes into play. It maps the identities from IDP to an anonymous user in the SP (many to one mapping).

This blog post was first published @ www.fedji.com, included here with permission.

This is the second entry from a series of four blog entries made around using SAML v2 Assertion attributes in an application protected by ForgeRock OpenAM. Reading/viewing this as an independent entry may not be a futile exercise, but it may seem more effective if the following order is followed while going through this topic:

So the diagram above shows a Circle of Trust established between two entities (an Identity Provider and a Service Provider), each of which is an OpenAM instance running in two different Linux Containers. In this scenario, a user (with id ‘demo’) has profile in both IDP and SP, and by virtue of Identity Federation, she manages to link those accounts, after which once she authenticates against the IDP, IDP can send a assertion to SP, validating the authenticity of the user.

This blog post was first published @ www.fedji.com, included here with permission.

This is first of four blog entries that aims at demonstrating how to use SAML Assertion Attributes in an Application protected by ForgeRock OpenAM. For the convenience of viewing, a thirty five odd minutes screen-cast has been split into four sections, the first of which is embedded on this blog post. While each entry talks of an independent facility in ForgeRock OpenAM, it makes sense to read/view them in the following order:

As you can possibly make out from the illustration above, there are three Linux Containers being used in our demonstration, two of which runs an OpenAM instance each. A third Linux Container is used for installing a J2EE Application. The illustration captures the end state of this segment, where a J2EE Application is protected by an OpenAM J2EE Agent, making sure all client requests to it are intercepted by the Agent and redirected to the OpenAM for Authentication/Authorization.