Quantcast
Channel: OpenAM – ForgeRock Community Blogs
Viewing all 66 articles
Browse latest View live

OpenAM Security Advisory #201507

$
0
0

Security vulnerabilities have been discovered in OpenAM components. These issues may be present in versions of OpenAM including 12.0.x, 11.0.x, 10.1.0-Xpress, 10.0.x, 9.x, and possibly previous versions.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues.

The maximum severity of issues in this advisory is Critical. Deployers should take steps as outlined in this advisory and apply the relevant update(s) at the earliest opportunity.

The recommendation is to deploy the relevant patches. Patch bundles are available for the following versions (in accordance with ForgeRock’s Maintenance and Patch availability policy):

  • 10.0.2
  • 11.0.2
  • 11.0.3
  • 12.0.0
  • 12.0.1
  • 12.0.2

Customers can obtain these patch bundles from BackStage.

Issue #201507-01: Business Logic Vulnerability

Product: OpenAM
Affected versions: 11.0.0-11.0.3, 12.0.1-12.0.2
Component: Core Server, Server Only
Severity: Critical

A specific type of request to /openam/frrest/oauth2/token endpoint can expose user tokens to another user.

Workaround:

Block all access to the /openam/frrest/oauth2/token endpoint.

Resolution:
Use the workaround or deploy the relevant patch bundle.

Issue #201507-02: Cross Site Scripting

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Component: Core Server, Server Only
Severity: High

OpenAM is vulnerable to cross-site scripting (XSS) attacks which could lead to session hijacking or phishing.
Affecting 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3 and 12.0.0-12.0.2:

  • /openam/ccversion/Masthead.jsp

Affecting 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3 and 12.0.0-12.0.2:

  • /openam/oauth2c/OAuthProxy.jsp

Workaround:

Protect the listed endpoints with the container (for example using the mod_security Apache module) or filter external requests until a patch is deployed.

Resolution:
Use the workaround or deploy the relevant patch bundle.


Unlocking the Authorization Asset

$
0
0

This blog post was first published @ http://identityrocks.blogspot.fr/, included here with permission.

Consumer identity is a core asset to your business. Unlocking authorization and leveraging it into your business processes and (micro) services helps you in this endeavor as it drives a yet higher level of personalization and how users interact with resources and objects.

In a recent post titled “Authorization for Everything” I outlined how any resource or object can be described in ForgeRock’s identity platform authorization framework by the example of a home cinema.

But who’s going to setup the authorization objects and controls ?
(Question by an attendee of the ForgeRock Identity Summit in Düsseldorf)

User facing applications that operate or control devices or resources, like mobile applications or smart remote controls, are now enabled to call directly in the authorization framework to manage or evaluate permissions. This is also possible go via a hub to which an appliance like the home cinema would register when it is plugged in.

Smart authorization is now unlocked to any of these procedures, services and applications regardless of the platform. And the key is the REST API provided by the ForgeRock identity platform.

The key to drive authorization in the user experience or device management is the API !
Implement it where it creates most value for the consumer.
(My answer)

In full detail now how to manage and evaluate authorization elements via REST by the example of a home cinema.

Authorization Management via REST in detail
Step 1: Creating a resource type TV

First we create a resource type TV and specify the format of how to address the resource (e.g. tv://myhouse/homecinema) and possible actions for the resource.

Request:
curl -s –request POST –header “Content-Type: application/json” –data @request.json https://sso.redstone.com:443/sso/json/authzrealm/resourcetypes?_action=create&_prettyPrint=true
Request (JSON):
{
“patterns”: [
“tv://*/*”
],
“name”: “tv”,
“actions”: {
“ENABLE”: true,
“DISABLE”: true,
“BROADCAST SCREEN”: true,
“BROADCAST CAMERA”: true
}
}
Response (JSON):
{
“uuid” : “9fefc18f-5731-4963-a8d6-fa8aba7923d4”,
“name” : “tv”,
“description” : null,
“patterns” : [ “tv://*/*” ],
“actions” : {
“DISABLE” : true,
“ENABLE” : true,
“BROADCAST CAMERA” : true,
“BROADCAST SCREEN” : true
},
“createdBy” : “id=amadmin,ou=user,dc=sso-config,dc=com”,
“creationDate” : 1447989190178,
“lastModifiedBy” : “id=amadmin,ou=user,dc=sso-config,dc=com”,
“lastModifiedDate” : 1447989190178
}
Note the resource type’s UUID in the response. This value is needed later to assign a resource type to a policy.


Step 2: Creating the policy set (or application)

Next the resource set (or application) needs to be created with the resourceTypeUUID containing the one of resource type TV.

Request:
curl -s –request POST –header “Content-Type: application/json” –data @request.json https://sso.redstone.com:443/sso/json/authzrealm/applications?_action=create&_prettyPrint=true
Request (JSON):
{    “name” : “SmartHome”,
“applicationType” : “iPlanetAMWebAgentService”,
“description” : “Controlling objects in a smart home.”,
“resourceTypeUuids” : [ “9fefc18f-5731-4963-a8d6-fa8aba7923d4”],
“subjects” : [ “Policy”, “NOT”, “OR”, “JwtClaim”, “AuthenticatedUsers”, “AND”, “Identity”, “NONE” ],
“entitlementCombiner” : “DenyOverride”,
“saveIndex” : null,
“searchIndex” : null,
“resourceComparator” : null,
“attributeNames” : [ ],
“editable” : true,
“conditions” : [ “LEAuthLevel”, “Policy”, “Script”, “AuthenticateToService”, “SimpleTime”, “AMIdentityMembership”, “OR”, “IPv6”, “IPv4”, “SessionProperty”, “AuthScheme”, “AuthLevel”, “NOT”, “AuthenticateToRealm”, “AND”, “ResourceEnvIP”, “LDAPFilter”, “OAuth2Scope”, “Session” ]
}
Response (JSON):
{
“lastModifiedBy” : “id=amadmin,ou=user,dc=sso-config,dc=com” ],
“lastModifiedDate” : 1447989192860,
“creationDate” : 1447989192860,
“createdBy” : “id=amadmin,ou=user,dc=sso-config,dc=com”,
“applicationType” : “iPlanetAMWebAgentService”,
“subjects” : [ “Policy”, “NOT”, “OR”, “JwtClaim”, “AuthenticatedUsers”, “AND”, “Identity”, “NONE” ],
“entitlementCombiner” : “DenyOverride”,
“saveIndex” : null,
“searchIndex” : null,
“resourceComparator” : null,
“attributeNames” : [ ],
“editable” : true,
“conditions” : [ “LEAuthLevel”, “Policy”, “Script”, “AuthenticateToService”, “SimpleTime”, “AMIdentityMembership”, “OR”, “IPv6”, “IPv4”, “SessionProperty”, “AuthScheme”, “AuthLevel”, “NOT”, “AuthenticateToRealm”, “AND”, “ResourceEnvIP”, “LDAPFilter”, “OAuth2Scope”, “Session” ],
“description” : “Controlling objects in a smart home.”,
“name” : “SmartHome”
}
Step 3: Creating the policy giving permissions to Bob

Next the resource set (or application) needs to be created with the resourceTypeUUID containing the one of resource type TV.

Request:
curl -s –request POST –header “Content-Type: application/json” –data @request.json https://sso.redstone.com:443/sso/json/authzrealm/policies?_action=create&_prettyPrint=true
Request (JSON):
{
“name” : “HomeCinema”,
“active” : true,
“description” : “”,
“applicationName” : “SmartHome”,
“actionValues” : {
“ENABLE” : true,
“DISABLE” : true,
“BROADCAST SCREEN” : true,
“BROADCAST CAMERA” : true
},
“resources” : [ “tv://myhouse/homecinema” ],
“subject” : {
“type” : “Identity”,
“subjectValues” : [ “id=bob,ou=user,o=authzrealm,ou=services,dc=sso-config,dc=com” ]
},
“resourceTypeUuid” : “9fefc18f-5731-4963-a8d6-fa8aba7923d4”
}
Response (JSON):
{
“name” : “HomeCinema”,
“active” : true,
“description” : “”,
“applicationName” : “SmartHome”,
“actionValues” : {
“DISABLE” : true,
“ENABLE” : true,
“BROADCAST CAMERA” : true,
“BROADCAST SCREEN” : true
},
“resources” : [ “tv://myhouse/homecinema” ],
“subject” : {
“type” : “Identity”,
“subjectValues” : [ “id=bob,ou=user,o=authzrealm,ou=services,dc=sso-config,dc=com” ]
},
“resourceTypeUuid” : “9fefc18f-5731-4963-a8d6-fa8aba7923d4”,
“lastModifiedBy” : “id=amadmin,ou=user,dc=sso-config,dc=com”,
“lastModifiedDate” : “2015-11-20T03:13:14.274Z”,
“createdBy” : “id=amadmin,ou=user,dc=sso-config,dc=com”,
“creationDate” : “2015-11-20T03:13:14.274Z”
}
Step 4: Evaluating the policy for user Bob

Next the resource set (or application) needs to be created with the resourceTypeUUID containing the one of resource type TV. For completeness – the procedure is already outlined in “Authorization for Everything” – here’s how an upstream application would evaluate if Bob can broadcast the screen (or any other action). 

Request URL:

https://sso.redstone.com:443/sso/json/authzrealm/policies?_action=evaluateTree&_prettyPrint=true

Request (JSON):
{
“application”: “SmartHome”,
“resource”: “tv://myhouse/homecinema”,
“subject”: {
“ssoToken”: “AQIC5wM2LY4SfcxbXJgKBtBsbzH0OtxslnEQDHK2RJ5UJho.*AAJTSQACMDIAAlNLABQtOTIwMDUyMDgxMTA2Mzk1NjIzMgACUzEAAjAx*”
}
}
Response (JSON):
[ {
“advices” : { },
“ttl” : 9223372036854775807,
“resource” : “tv://myhouse/homecinema”,
“actions” : {
“DISABLE” : true,
“ENABLE” : true,
“BROADCAST CAMERA” : true,
“BROADCAST SCREEN” : true
},
“attributes” : { }
} ]

If you want to go further, look at the details of policy creation via REST, policy evaluation or maybe even reproduce my demo at the Identity Summit in Düsseldorf, check the openam-high5 GitHub project. In particular the 652-authz-create-policy and 654-authz-evaluate-policy-tv.

 

ForgeRock OpenAM Deployment Training in Bangalore, India

$
0
0

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

Just yesterday, I concluded a five day ForgeRock University training program on ForgeRock OpenAM at Bangalore. I wish to express my sincere gratitude to each one in the picture below for showing up for a ForgeRock University course on our Access Management solution and wish them success in their ForgeRock Projects.

OpenAMDeploymentTraining
To know what we discussed during the training or to subscribe for one such program, all details are here.

If you aren’t looking for a detailed program on our Products as the one you find in the link above, we do offer half a day free (as in beer) overview session on both ForgeRock OpenAM and ForgeRock OpenIDM, the details of which are below (keep checking the links below for the next occurrence):

ForgeRock OpenAM Product Overview
ForgeRock OpenIDM Product Overview

Lastly, if you are keen to validate/demonstrate your skills in ForgeRock OpenAM, check out ForgeRock Certified OpenAM Specialist Exam.

Again, to all my friends who dropped by for the OpenAM training, thanks for all the fun and learning.

OpenAMTrainingCollage

MySQL Database as Identity Repository for ForgeRock OpenAM

$
0
0

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

ForgeRock OpenAM has three types of repositories:

(i) Configuration Repository that stores the OpenAM configuration data (ForgeRock OpenDJ)
(ii) Authentication Repository that’s used by OpenAM to Perform User Authentication (has more than 20 options out of the box)
(iii) Identity Repository that stores the User Profiles (has several options like LDAP v3, OpenDJ, AD, IBM’s Directory Server and Database [Eary Access])

Someone asked me the details on configuring a Database as the Identity Repository for ForgeRock OpenAM, so as soon as I got a chance, created the following screen-cast to demonstrate the use of MySQL Database as an Identity Repository for ForgeRock OpenAM. It’s fairly straightforward.

Enjoy!

How to configure social authentication with LinkedIn

$
0
0

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

When trying to configure Social Authentication with OpenAM 12 you may notice that out of the box OpenAM only supports Microsoft, Google and Facebook. The reasoning behind this is that at the time of the implementation these providers supported OpenID Connect (well Facebook supports Facebook Connect, but that’s close enough). In case you would like to set up social authentication with other providers then that is still possible, but a bit tricky. In this article I’m going to try to show how social authentication can be configured for example with LinkedIn (that currently only supports OAuth2, not OIDC).

Create an OAuth2 app at LinkedIn

In order to be able to obtain OAuth2 access tokens from LinkedIn, you will need to register your OpenAM as a LinkedIn application by filling out some silly forms. The second page of this wizard gets a bit more interesting, so here are a couple of things that you should do:

  • Take a note of the Client ID and Client Secret displayed.
  • Make sure that OpenAM’s Redirect URI is added as a valid OAuth 2.0 Authorized Redirect URLs, by default that would look something like:
    http://openam.example.com:8080/openam/oauth2c/OAuthProxy.jsp
    

Configure OpenAM for Social authentication

To simply configure LinkedIn for OAuth2 based authentication, you just need to create a new authentication module instance with OAuth 2.0 / OpenID Connect type. With ssoadm that would look something like:

$ openam/bin/ssoadm create-auth-instance -e / -m linkedin -t OAuth -u amadmin -f .pass

This just configures an OAuth2 authentication module with the default settings, so now let’s update those settings to actually match up with LinkedIn:

$ openam/bin/ssoadm update-auth-instance -e / -m linkedin -u amadmin -f .pass -D linkedin.properties

Where linkedin.properties contains:

iplanet-am-auth-oauth-client-id=
iplanet-am-auth-oauth-client-secret=
iplanet-am-auth-oauth-auth-service=https://www.linkedin.com/uas/oauth2/authorization
iplanet-am-auth-oauth-token-service=https://www.linkedin.com/uas/oauth2/accessToken
iplanet-am-auth-oauth-scope=r_basicprofile
iplanet-am-auth-oauth-user-profile-service=https://api.linkedin.com/v1/people/~?format=json
org-forgerock-auth-oauth-account-mapper-configuration=id=uid
org-forgerock-auth-oauth-attribute-mapper-configuration=lastName=sn
org-forgerock-auth-oauth-attribute-mapper-configuration=firstName=givenName
org-forgerock-auth-oauth-attribute-mapper-configuration=id=uid
org-forgerock-auth-oauth-prompt-password-flag=false

At this stage you should be able to authenticate with LinkedIn by simply opening up /openam/XUI/#login/&module=linkedin .

To set up this OAuth2 module for social authentication you just need to do a few more things:
Add the authentication module to a chain (social authentication uses authentication chains to allow more complex authentication flows):

$ openam/bin/ssoadm create-auth-cfg -e / -m linkedinChain -u amadmin -f .pass
$ openam/bin/ssoadm add-auth-cfg-entr -e / -m linkedinChain -o linkedin -c REQUIRED -u amadmin -f .pass

Now to enable the actual social authentication icon on the login pages, just add the Social authentication service to your realm:

$ openam/bin/ssoadm add-svc-realm -e / -s socialAuthNService -u amadmin -f .pass -D social.txt

Where social.txt contains:

socialAuthNDisplayName=[LinkedIn]=LinkedIn
socialAuthNAuthChain=[LinkedIn]=linkedinChain
socialAuthNIcon=[LinkedIn]=https://static.licdn.com/scds/common/u/images/logos/linkedin/logo_in_nav_44x36.png
socialAuthNEnabled=LinkedIn

Please keep in mind that OAuth2 is primarily for authorization purposes, for authentication you should really utilize OpenID Connect as a protocol. As the social authentication implementation is quite generic, actually you should be able to configure any kind of authentication mechanism and display it with a pretty logo on the login page if you’d like.

Some links I’ve found useful when writing up this post:
OpenAM 12 – Social Authentication
LinkedIn OAuth2 docs
LinkedIn REST API

Distributed Authentication in ForgeRock OpenAM

$
0
0

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

Let me start with a word of caution. I made a screen-cast to demonstrate the Distributed Authentication in ForgeRock OpenAM and you’ll find the same embedded on this post. Some of my actions in there are questionable and should never be attempted even in a development environment, such as setting a URL in the OpenAM Administration Console to redirect to after a Successful Authentication. This video demonstration is solely intended to give a hint on the positioning of Distributed Authentication UI in OpenAM Deployment Topology, but several other things like Network/Firewall configuration, Post Authentication Processing that goes hand in hand with the Distributed Authentication in OpenAM was beyond the scope of this short screen-cast. I really hope you get an idea on what the Distributed Authentication in OpenAM is expected to achieve.

The following illustration might give you an idea on what’s demonstrated in the video. We have a client network who cannot (or who is not supposed to) access the OpenAM Server in a different Network directly (say for Security reasons). So in a Demilitarized Zone (DMZ) or Perimeter Network, we have a Server that offers a Distributed Authentication UI to the clients from the ‘untrusted network’. That way, the clients get to see the UI of OpenAM by access the Server in DMZ, who would in turn talk to the OpenAM Server through a trusted channel. As one can imagine, Network Configuration like Firewall plays an important role in a deployment scenario, but sadly that’s all beyond the scope in our mini demonstration.

DistributedAuthUI
So if you have ~10 minutes to spare, watch it

Enjoy!

Thanks: ForgeRock Documentation on OpenAM

SAML2 in-chain authentication – The SAML2 Auth Module

$
0
0
The SAML2 authentication module is a new addition to OpenAM13. It comprises three new components which work together along with OpenAM’s SAML2 implementation to provide integrated SAML2 authentication to a standard OpenAM authentication chain. There are some limitations on the use of the new module – it supports HTTP-Artifact and HTTP-POST bindings and HTTP-Redirect and HTTP-POST request bindings. The new components are:
      • A new SAML2 authentication module
This is the authentication module that performs the bulk of the work. It handles identifying the user by sending them off to the remote identity provider, and – if appropriate – executing a sub-authentication chain which links the remote account to a local one.
      • A new assertion consumer endpoint
This assertion consumer endpoint differs slightly from the default OpenAM SAML2 endpoint, as it knows that it’s responsible for pushing the user agent back into the appropriate authentication chain. A SAML2 SP which utilises the authentication module must
      use the new assertion consumer endpoint.
    • A new post authentication plugin
This acts to enable IdP-initiated single logout support, and to configure and enable SP-initiated single logout. If you’re familiar with the function of OpenAM 12’s SP implementation, the authentication module’s configuration page will be very familiar to you. The parameters filled in here can – for the most part – be thought of simply as query parameters which would be sent to the old spsssoinit endpoint. Each option is explained in terms of its function in relation to the SAML2 process both in the administrator UI and the OpenAM 13 documentation, as such they won’t be enumerated here. However, articles here will cover the options necessary to configure to be able to set up each example. The SAML2 authentication module is a first factor module. That is, it results in the authentication modules following this module knowing the identity of the user in the local datastore the SAML2 module pointed to. This may be a newly Federated and generated user (see Dynamic Account Federation and Local Account Linking Account Federation examples) or an anonymous user (see article Anonymous Session Generation With Attribute Federation). Finally, the SAML2 authentication module is the first module to contain the ability to perform a secondary authentication chain whose result acts as a component to this module. All this is explained in the Local Account Linking Federation example.

Enabling Single Log Out Support

$
0
0
The SAML2 Post Authentication Plugin (org.forgerock.openam.authentication.modules.saml2.SAML2PostAuthenticationPlugin) is an optional component which can be added to a chain which includes the SAML2 authentication module. It is responsible for configuring the session in such a way that it correctly responds to IdP-initiated single logout requests, and can additionally be configured to support SP-initiated single logout.

Supporting IdP-initiated single logout

By adding the SAML2 Post Authentication Plugin to your authentication chain, sessions which are logged in to your SP will be logged out when the IdP initiates logout (this may be a rather jarring experience for them, as they will simply be kicked out of the system upon the next action performed in the SP’s service). There is no additional configuration required, and supporting SP-initiated single logout is not required if not desired.

Supporting SP-initiated single logout

By setting the Single Logout Enabled boolean inside the authentication module’s configuration to true, a request to log out from the SP will attempt to log out the IdP’s logged in session also. Upon successful logout from the IdP, the user will be redirected to the value provided in the Single Logout URL field – this value must be a fully-qualified URL. You may not support SP-initiated single logout without supporting IdP-initiated single logout.

Using SAML Assertion Attributes in ForgeRock OpenAM – Episode 01/04 : Protecting a J2EE Application with ForgeRock OpenAM

$
0
0

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:

1. Protecting a J2EE Application with ForgeRock OpenAM
2. Configuring Federation in ForgeRock OpenAM
3. Configuring Transient Federation in ForgeRock OpenAM
4. Using SAMLv2 Assertion Attributes

Image01

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.

Enjoy!


https://youtu.be/YeUwfjVPMks

Using SAML Assertion Attributes in ForgeRock OpenAM – Episode 02/04 : Configuring SAML 2.0 Federation in ForgeRock OpenAM

$
0
0

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:

1. Protecting a J2EE Application with ForgeRock OpenAM
2. Configuring Federation in ForgeRock OpenAM
3. Configuring Transient Federation in ForgeRock OpenAM
4. Using SAMLv2 Assertion Attributes

At end of this episode, the following is what you get:

image03

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.

Enjoy!

Using SAML Assertion Attributes in ForgeRock OpenAM – Episode 03/04 : Configuring Transient Federation in ForgeRock OpenAM

$
0
0

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:

1. Protecting a J2EE Application with ForgeRock OpenAM
2. Configuring Federation in ForgeRock OpenAM
3. Configuring Transient Federation in ForgeRock OpenAM
4. Using SAMLv2 Assertion Attributes

Let me throw a picture at you:

image04

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).

Enjoy!

Using SAML Assertion Attributes in ForgeRock OpenAM – Concluding Episode: Using SAML Assertion Attributes

$
0
0

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:

1. Protecting a J2EE Application with ForgeRock OpenAM
2. Configuring Federation in ForgeRock OpenAM
3. Configuring Transient Federation in ForgeRock OpenAM
4. Using SAMLv2 Assertion Attributes

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

image05

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.

Enjoy!

ForgeRock OpenAM 13 User Self Service

$
0
0

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

ForgeRock’s recently released newer version of its Access Management solution offers many new and improved User Self Service experience. It’s all self-explanatory in the video embedded below. Please take a look, when you’ve ten minutes:

Enjoy!

Impersonation Authentication module for OpenAM

$
0
0

Introduction

Support for impersonation is useful in the enterprise use cases where designated administrators are required to act on behalf of a user in certain scenarios. By impersonating another user an administrator, if authorized to do so, gains access to a restricted view of the user’s profile in the system. This is helpful in situations involving password reset, request-based access and profile updates. However, the design of such a system must call for controls that actively restrict access to the user’s entitlements at the outset. This can be achieved using step-up authentication for gaining access to private user data, and also by using the OpenAM policy engine for performing advanced resource-based decisioning.

Configuration

An OpenAM custom authentication module was written to enable impersonation support. The module requires input of the username of the end-user being impersonated and the administrator credentials. After submitting the username and password, the admin account is authenticated first and then it is also authorized to complete the impersonation request using REST calls to a specified OpenAM Policy endpoint. This policy can be either local or external as we shall examine further. The impersonated user is also validated for being in active status in the system. If all is okay, the administrator is permitted to impersonate and OpenAM creates a session for the impersonated user. The module can be configured using the following gauges to complete the described functions correctly:

  1. Setup the resource-set you want to check policy for. This resource set its nothing but a special URL that invokes policy evaluation for impersonation
  2. The authentication realm you want the administrator to authenticate in. The authentication module allows for realm-specific authentication
  3. The OpenAM server where the policy resides, the realm where the policy resides, and the policy-set name. The policy does not need to be local and can be on a remote policy host
  4. Check whether you want the administrator to be a member of a local group as well, in addition to the external policy authorization.
A step by step account of the workings of the module follows.

Development

Configuration read from Module Instance

options -> {iplanet-am-auth-check-group-membership=[True], iplanet-am-auth-impersonation-hash-enabled=[true], iplanet-am-auth-authentication-realm=[authn], iplanet-am-auth-impersonation-auth-level=[1], iplanet-am-auth-resource-set=[http://openam:8080/openam/index.html], moduleInstanceName=impersonate, iplanet-am-auth-impersonation-id=[Enter the user id to impersonate?], iplanet-am-auth-impersonation-group-name=[impersonation], iplanet-am-auth-openam-server=[http://openam:8080/openam], iplanet-am-auth-policy-realm=[impersonation], iplanet-am-auth-policy-set-name=[impersonation]}

Authorize the administrator locally

In our test scenario, the ‘user.0’ is really an administrative user that has been granted membership to the group named ‘impersonation’, as configured in the module (see above).

We build an AMIdentity object for the group and validate membership.

[AMIdentity object: id=impersonation,ou=group,o=impersonation,ou=services,dc=openam,dc=forgerock,dc=org]
value of attribute: uid=user.0,ou=People,dc=forgerock,dc=com
userName to check: user.0
match found! admin: user.0 allowed to impersonate user: user.1

Authorize the Administrator

Get the ssotoken for the admin who is trying to impersonate via a policy call, and authenticate the user to the realm specified in the config

json/authn/authenticate response-> {"tokenId":"AQIC5wM2LY4Sfcxokjvdayf3ig0oDuQITXRTWT9B_3hq72A.*AAJTSQACMDEAAlNLABI1ODk0Nzg1NTEyNDUzNzcxNDI.*","successUrl":"/openam/console"}
tokenId-> AQIC5wM2LY4Sfcxokjvdayf3ig0oDuQITXRTWT9B_3hq72A.*AAJTSQACMDEAAlNLABI1ODk0Nzg1NTEyNDUzNzcxNDI.*

 

Build the 2nd policy rest call, and use the resource set, openam server, policy set and policy container from the configuration passed to the module.

stringentity-> {"resources": ["http://openam:8080/openam/index.html"],"application":"impersonation", "subject": {"ssoToken":"AQIC5wM2LY4Sfcxokjvdayf3ig0oDuQITXRTWT9B_3hq72A.*AAJTSQACMDEAAlNLABI1ODk0Nzg1NTEyNDUzNzcxNDI.*"}}
json/impersonation/policies?_action=evaluate response-> [{"advices":{},"actions":{"POST":true,"PATCH":true,"GET":true,"DELETE":true,"OPTIONS":true,"PUT":true,"HEAD":true},"resource":"http://openam:8080/openam/index.html","attributes":{"uid":["user.0"],"cn":["Javed Shah"],"roleName":["timeBoundAdmin"]}}]

Custom response attributes can be passed back to the module for further evaluation if needed. For example, a statically defined roleName=timeBoundAdmin could be used to further restrict this impersonation request within the time window specified in the ‘timeBoundAdmin’ control. This example is only given to seed the imagination, the module currently does not restrict the impersonation session using a time window, but this is possible to do.

Parse the JSON response from Policy Evaluation

jsonarray-> {"resource":"http://openam:8080/openam/index.html","attributes":{"uid":["user.0"],"cn":["Javed Shah"],"roleName":["timeBoundAdmin"]},"advices":{},"actions":{"POST":true,"PATCH":true,"GET":true,"DELETE":true,"OPTIONS":true,"HEAD":true,"PUT":true}}
If the ACTION set returned for GET/POST is TRUE, the admin is permitted to impersonate. This could be extended to include other actions as necessary. Finally, destroy the admin session, now that it is not needed anymore and return the impersonated user as the Principal for constructing an OpenAM session.

Demo

Our short demo begins with the administrator being asked for the username of the user they want to impersonate.
Next, the module asks for the admin credentials.
If the administrator is unable to authenticate, or does not belong to the local group, or fails external policy evaluation, the following error screen is shown.
If all checks pass, the adminsitrator is granted the user’s session and logs into OpenAM.

Source

This article was first published on the OpenAM Wiki Confluence site: Impersonation in OpenAM

Google+ Social Login Risk Profiling using ZeroFOX

$
0
0

Introduction

ZeroFOX Enterprise evaluates and records the risk associated with social media users and organizations. This evaluation is conducted through the ZeroFOX Enterprise security analysis engine which analyzes the full social graph for a targeted user to include their associated people, organizations and interactions.

The ZeroFOX Social Risk Score API allows OpenAM to query the ZeroFOX Enterprise Platform RESTful API for risk attributes associated with a given social media asset- social media user or organization. If ZF does not have recent ZeroFOX data on the requested asset, it is immediately submitted for analysis and can be queried again at a later time.

For purposes of this demo with Google Plus, I created a custom OpenAM 13 build that enables chaining the Scripted Authentication Module to the OAuth module. The custom build also enables passing an Authorization header into the httpClient POST API in the server-side script. On every login attempt from a Social Login platform, the Scripted Authentication Module invokes the ZF api with an Authorization header to assess the risk associated with the login.

The following risk attributes can be flagged on a social account and each one of these can be detected from within the Scripted Authentication Module in OpenAM via the ZeroFOX Social Login Risk Score API.

Configuration

From Common Tasks, under the “Configure Social Authentication” menu, select and configure ‘Configure Google Authentication’.

Create a Scripted Authentication Module instance in OpenAM. Add code in the server side script to invoke the ZF API:

httpClient.post("https://api.zerofox.com/1.0/sra/", "{"network":"google+", "user_id":"+userId +"}", {cookies:[], headers:[{"field": "Content-type","value":"application/json"},{"field": "Authorization","value": "forgerock:*******"}]});

Chain the Scripted Authentication Module instance to the GoogleSocialAuthentication instance created in the previous step:

In Google Plus, open a test account and post a phishing link. At this point you should kick off the scan by invoking the ZF API from Postman or using curl. If you do not do it now, the scan is started when you attempt to login into OpenAM using this malicious account, except of course, the Social Login Score is not ready just yet and authentication passes.

Demo

From the OpenAM login page, click on the Google Plus icon to login:

Login as the malicious user and you should immediately see an Authentication denied error. The Scripted Authentication Module checks for high threat indicators and denies login if one or more are found.

Using Postman, invoking the ZF Social Login Score API confirms that phishing links were found on the account and threat level is too high to allow login into OpenAM.

{
  • "phishing": "2015-04-24 17:13:24 UTC",
  • "drugs_and_alcohol": "2015-04-24 17:09:24 UTC",
  • "malware": "2015-04-24 17:13:24 UTC"
}

Integration with PaloAlto Networks Panorama

$
0
0

Introduction

Palo Alto Networks virtualized firewalls, called the VM-Series support the exact same next-generation firewall and advanced threat prevention features available in their physical form factor appliances, allowing customers to safely enable applications flowing into, and across their private, public and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups and a REST-based API allow developers and administrators to proactively monitor VM changes dynamically feeding that context into security policies, thereby eliminating the policy lag that may occur when the Virtual Machines change.

Consider the following use case:

A customer of Palo Alto Networks has firewalls protecting an insurance & claims Portal. The customer seeks an identity & access management platform with following key capabilities:
a) Onboard millions of existing users from existing internet-facing Directory Server
b) Provide a self registration capability for new customers with a new policy (individual or via employer)
c) Be able to detect portal sessions, and selectively enable enterprise applications in the Portal for customers, affiliates and partners alike.

The ForgeRock powered Palo Alto Networks solution provides all these key capabilities.

Users login to the Portal, protected by OpenAM distributed User Interface living in the DMZ. Upon successful authentication, OpenAM punches application-specific ports in the Palo Alto Networks firewall(s) on behalf of the user via the Palo Alto Networks User-ID API. This powerful real-time action instantly enables user access to Portal iFrames, AJAX widgets (etc) to make inbound API calls to retrieve live policy, insurance or claims content. When the user logs out of Portal, OpenAM instantly closes the application-specific ports via the Palo Alto Networks User-ID API. This real-time action instantly disables access to the specific applications for the user.

This page describes a simpler use case, wherein REST calls are used to log into OpenAM directly, triggering User-Id API calls in the backend to open and subsequently close application ports in the virtualized firewalls managed by Panorama.

 

Technical Overview

All software used in this demo is on evaluation virtual appliances from Palo Alto Networks.

Download, install and configure Panorama 6 to connect to two 5.0.6 firewalls and two 6.0.0 firewalls. For this demo we shall only be using the 6.0.0 firewall.

Note that Panorama has to have the highest version always. The managed firewalls can be the same version as Panorama or older.

Finally, Panorama 6 needs to be run on a 64 bit ESXi host.

Generate an API key that needs to be sent with every REST call using the endpoint: http(s)://hostname/api/?type=keygen&user=username&password=password 

Note that the API returns separate keys each time a keygen query is run. All of the returned keys are valid.

When installations and configurations are done, you should see the virtualized firewalls in a connected state from the Panorama interface:

Write a post authentication plugin (PaP) in OpenAM that uses the Palo Alto Networks REST-based User-ID API to open up an application port in Panorama-managed firewalls.

The PaP creates a user-id mapping file under /tmp, such as the following:

<?xml version="1.0" encoding="UxTF-8"?>
<uid-message>
<payload><login>
<entry blocksize="2" endport="8081" ip="10.0.61.20" name="demo" startport="8080"/></login>
</payload>
<type>update</type>
<version>1.0</version>
</uid-message>

The PaP uploads this XML file to the endpoint: http://hostname/api/?type=user-id&action=set&key=api-key&target=firewall-serial-number

The endpoint is the Panorama listener that dispatches the incoming User-ID API “set” request to the target firewall specified in the target parameter.

Demo

Here is the step by step flow:

Login to OpenAM as demo via curl:

The Post Authentication Plugin creates the API payload and upload it to the Panorama endpoint specifying the target managed firewall.

The User-ID API “punches” an access-grant into the virtualized firewall as shown here. This access-grant happens to never expire in our demo, however, it could be time bounded.

The user logs out via CURL as shown here:

The request is sent to the same target:

The user access, previously granted is now unblocked as shown here.

That sums up this simple demo.

 

This article was first published on the OpenAM Wiki Confluence site: OpenaM and PaloAlto Networks

Invoking HOTP over REST

$
0
0

HOTP Introduction

An excellent article about the core OpenAM HOTP capability is: Use HOTP for two factor authentication

Building on the article, we show here a typical REST-based programmatic interaction when invoking HOTP from a client, such as a Portal.

Configuration in OpenAM

Setup HOTP as REQUISITE after DataStore under a realm called “levels”. You could choose not to use realms and create the authentication chain at the top level realm. However, you would modify the REST URL for all the ensuing calls.

Using PostMan, invoke a POST on the realm=/levels

Body-

Empty

Response-

{ "authId": "eyAiYWxnIjogIkhTMjU2IiwgInR5cCI6ICJqd3QiIH0.eyAib3RrIjogIm05ZWVpdjltNmsxdGRoN2dkdGM4MG5qdWFmIiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3hieHYzZjI0aXlzNDlEaG9NUlU3VENhMkU3dFdfcXY1Zy4qQUFKVFNRQUNNREVBQWxOTEFCUXROelU0TmpBME1UZzJNVFl5TWpnNU5EWXdOZy4uKiIsICJyZWFsbSI6ICJvPWxldmVscyxvdT1zZXJ2aWNlcyxkYz1vcGVuYW0sZGM9Zm9yZ2Vyb2NrLGRjPW9yZyIgfQ.SsOE-9DyAZ6apnj5SXaD9ED28T_RDFfpjV8hslHP99g", "template": "", "stage": "DataStore1", "callbacks": [ { "type": "NameCallback", "output": [ { "name": "prompt", "value": " User Name: " } ], "input": [ { "name": "IDToken1", "value": "" } ] }, { "type": "PasswordCallback", "output": [ { "name": "prompt", "value": " Password: " } ], "input": [ { "name": "IDToken2", "value": "" } ] } ] }

 

Add in the username and password as shown below:

Body (from the screenshot above)-

{ "authId": "eyAiYWxnIjogIkhTMjU2IiwgInR5cCI6ICJqd3QiIH0.eyAib3RrIjogIjl2Mm1lZGQ3NmpwdXViZGlncGkyZjFtNzk5IiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3d1amwzczR4TXdyMHI0S3paMFI2Qmk3LV9aTHMxcnRQby4qQUFKVFNRQUNNREVBQWxOTEFCTXlOelE1TmpJeU5qUTBOVFUwTlRreE5EQTMqIiwgInJlYWxtIjogIm89bGV2ZWxzLG91PXNlcnZpY2VzLGRjPW9wZW5hbSxkYz1mb3JnZXJvY2ssZGM9b3JnIiB9.WGemKm2u0O-vbhAkAClg0l0rndGEhDbhS3pncAsn6PA", "template": "", "stage": "DataStore1", "callbacks": [ { "type": "NameCallback", "output": [ { "name": "prompt", "value": " User Name: " } ], "input": [ { "name": "IDToken1", "value": "user.4" } ] }, { "type": "PasswordCallback", "output": [ { "name": "prompt", "value": " Password: " } ], "input": [ { "name": "IDToken2", "value": "Password2" } ] } ] }

 

Response

{ "authId": "eyAiYWxnIjogIkhTMjU2IiwgInR5cCI6ICJqd3QiIH0.eyAib3RrIjogIjl2Mm1lZGQ3NmpwdXViZGlncGkyZjFtNzk5IiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3d1amwzczR4TXdyMHI0S3paMFI2Qmk3LV9aTHMxcnRQby4qQUFKVFNRQUNNREVBQWxOTEFCTXlOelE1TmpJeU5qUTBOVFUwTlRreE5EQTMqIiwgInJlYWxtIjogIm89bGV2ZWxzLG91PXNlcnZpY2VzLGRjPW9wZW5hbSxkYz1mb3JnZXJvY2ssZGM9b3JnIiB9.WGemKm2u0O-vbhAkAClg0l0rndGEhDbhS3pncAsn6PA", "template": "", "stage": "HOTP2", "callbacks": [ { "type": "PasswordCallback", "output": [ { "name": "prompt", "value": " Enter OTP " } ], "input": [ { "name": "IDToken1", "value": "" } ] }, { "type": "ConfirmationCallback", "output": [ { "name": "prompt", "value": "" }, { "name": "messageType", "value": 0 }, { "name": "options", "value": [ " Submit OTP ", " Request OTP " ] }, { "name": "optionType", "value": -1 }, { "name": "defaultOption", "value": 0 } ], "input": [ { "name": "IDToken2", "value": 0 } ] } ] }

 

Set IDToken2 to value “1”, and re submit as a POST. OpenAM will generate the OTP code and send it to the user.

 

Body-

{ "authId": "eyAiYWxnIjogIkhTMjU2IiwgInR5cCI6ICJqd3QiIH0.eyAib3RrIjogImYwZW5xYTI2aHZla3Q0bG5tc24wbDFlbTI5IiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3k4cllnb2V3MDBWNkpOUW5rR1RjLVoyVjZmcjZFMS11US4qQUFKVFNRQUNNREVBQWxOTEFCTTRNak01TXpRMU9EazROekl4TlRnNU16UXkqIiwgInJlYWxtIjogIm89bGV2ZWxzLG91PXNlcnZpY2VzLGRjPW9wZW5hbSxkYz1mb3JnZXJvY2ssZGM9b3JnIiB9.Dfxj7bAtxHEenVPA_9t3iCFhu92zqk8lXAqxmQD1COU", "template": "", "stage": "HOTP2", "callbacks": [ { "type": "PasswordCallback", "output": [ { "name": "prompt", "value": " Enter OTP " } ], "input": [ { "name": "IDToken1", "value": "" } ] }, { "type": "ConfirmationCallback", "output": [ { "name": "prompt", "value": "" }, { "name": "messageType", "value": 0 }, { "name": "options", "value": [ " Submit OTP ", " Request OTP " ] }, { "name": "optionType", "value": -1 }, { "name": "defaultOption", "value": 0 } ], "input": [ { "name": "IDToken2", "value": 1 } ] } ] }

 

Response-

{ "authId": "eyAiYWxnIjogIkhTMjU2IiwgInR5cCI6ICJqd3QiIH0.eyAib3RrIjogImYwZW5xYTI2aHZla3Q0bG5tc24wbDFlbTI5IiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3k4cllnb2V3MDBWNkpOUW5rR1RjLVoyVjZmcjZFMS11US4qQUFKVFNRQUNNREVBQWxOTEFCTTRNak01TXpRMU9EazROekl4TlRnNU16UXkqIiwgInJlYWxtIjogIm89bGV2ZWxzLG91PXNlcnZpY2VzLGRjPW9wZW5hbSxkYz1mb3JnZXJvY2ssZGM9b3JnIiB9.Dfxj7bAtxHEenVPA_9t3iCFhu92zqk8lXAqxmQD1COU", "template": "", "stage": "HOTP2", "callbacks": [ { "type": "PasswordCallback", "output": [ { "name": "prompt", "value": " Enter OTP " } ], "input": [ { "name": "IDToken1", "value": "" } ] }, { "type": "ConfirmationCallback", "output": [ { "name": "prompt", "value": "" }, { "name": "messageType", "value": 0 }, { "name": "options", "value": [ " Submit OTP ", " Request OTP " ] }, { "name": "optionType", "value": -1 }, { "name": "defaultOption", "value": 0 } ], "input": [ { "name": "IDToken2", "value": 1 } ] } ] }

 

Supply OTP Code

Change IDToken2 to value “0” and this time have the user supply the OTP code s/he received:

 

Body-

{ "authId": "eyAiYWxnIjogIkhTMjU2IiwgInR5cCI6ICJqd3QiIH0.eyAib3RrIjogImYwZW5xYTI2aHZla3Q0bG5tc24wbDFlbTI5IiwgInNlc3Npb25JZCI6ICJBUUlDNXdNMkxZNFNmY3k4cllnb2V3MDBWNkpOUW5rR1RjLVoyVjZmcjZFMS11US4qQUFKVFNRQUNNREVBQWxOTEFCTTRNak01TXpRMU9EazROekl4TlRnNU16UXkqIiwgInJlYWxtIjogIm89bGV2ZWxzLG91PXNlcnZpY2VzLGRjPW9wZW5hbSxkYz1mb3JnZXJvY2ssZGM9b3JnIiB9.Dfxj7bAtxHEenVPA_9t3iCFhu92zqk8lXAqxmQD1COU", "template": "", "stage": "HOTP2", "callbacks": [ { "type": "PasswordCallback", "output": [ { "name": "prompt", "value": " Enter OTP " } ], "input": [ { "name": "IDToken1", "value": "86848280" } ] }, { "type": "ConfirmationCallback", "output": [ { "name": "prompt", "value": "" }, { "name": "messageType", "value": 0 }, { "name": "options", "value": [ " Submit OTP ", " Request OTP " ] }, { "name": "optionType", "value": -1}, { "name": "defaultOption", "value": 0 } ], "input": [ { "name": "IDToken2", "value": 0 } ] } ] }

 

At this time, if the OTP code was correct, the user will be logged into OpenAM.

The value of the iPlanetDirectoryPro cookie will be returned as tokenId.

 

Response-

{ "tokenId": "AQIC5wM2LY4Sfcyt-pO9V3hEMYK924cDC2_SlWLROXUBpsc.*AAJTSQACMDEAAlNLABQtMTcyMDQ4ODk5NTU0ODUzNTQ4MQ..*", "successUrl": "/openam/console" }

 

The iPlanetDirectoryPro can then be used to do other stuff, such as list user data values over REST:

ForgeRock OpenIG 4 – Getting Credentials from ForgeRock OpenAM 13

$
0
0

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

Interested to see how ForgeRock Identity Gateway orchestrates with the ForgeRock Access Management solution to replay a User Credential on to a Legacy Application giving him/her access to it? There’s a screen-cast right below this write up. I had already posted a couple of entries on this space, demonstrating how OpenIG fetches User Credentials from different Datastores like a CSV file and a JDBC Database. While it’s not a prerequisite to know it before viewing the Video below, it might help get a good grip on the steps performed. So if you haven’t come across those blog entries yet, here it is:

ForgeRock OpenIG 4 – Getting Credentials from File Datastore
ForgeRock OpenIG 4 – Getting Credentials from Database

What to expect in the video?

– A user tries to access ‘http://openig.mydomain.com:8080/replay’ url
– A Java EE OpenAM Policy Agent sitting in front of the ‘http://openig.mydomain.com:8080′ url intercepts the request from the client (user’s browser) and redirects the request to ForgeRock OpenAM (http://openam.mydomain.com:8080/openam)
– ForgeRock OpenAM will send the OpenAM Login Page back to the user
– The user supplies the credential, which the OpenAM verifies. If authentication is successful,OpenAM adds the username of the user and his/her encrypted password to the session and sends it to Java EE Policy Agent
– Java EE Policy agent validates the user’s session, gives control to OpenIG.
– Because the URL that the client requested for (http://openig.mydomain.com:8080/replay), matches a specific route (say 04-route.json) configured in OpenIG, it applies the filters in the route configuration file. The first filter will use a shared key (also known to the OpenAM) to decrypt the encrypted password sent by OpenAM. The second filter will retrieve the username and password from the exchange and replaces your browser’s original HTTP GET request with an HTTP POST login request that contains the credentials to authenticate and the third filter will remove the username and password headers before continuing to process the exchange.
– The HTTP server validates the credentials and respond back to OpenIG with user’s profile page
– OpenIG sends that response to the End user

Note: OpenAM in our setup is configured to process a ‘Password Replay’ Java Class on successful authentication. The Java EE agent in OpenAM is configured only for Single Sign On (SSO) and is configured to add the UserToken (username) and sunIdentityUserPassword (password) as session attributes in HTTP header. And the FQHN of OpenAM deployment in the Video demonstration is ‘idp.mydomain.com’ and not ‘openam.mydomain.com’

To satisfy your Visual Cortex, here’s an illustration of the steps above:

OpenIG Fetching Credentials from OpenAM-Modified

Now on to the step by step configuration. Enjoy!

Related Documentation / Video:
– ForgeRock OpenIG Documentation
– Screncast on ‘ForgeRock OpenIG 3.x : Getting Credentials from OpenAM

OpenAM v.13 – REST STS OpenAM Token Translation

$
0
0

A quick demo of OpenAM’s Token Translation Service

According to Wikipedia:

In a typical usage scenario, a client requests access to a secure software application, often called a relying party. Instead of the application authenticating the client, the client is redirected to an STS. The STS authenticates the client and issues a security token. Finally, the client is redirected back to the relying party where it presents the security token. The token is the data record in which claims are packed, and is protected from manipulation with strong cryptography. The software application verifies that the token originated from an STS trusted by it, and then makes authorization decisions accordingly. The token is creating a chain of trust between the STS and the software application consuming the claims. This process is illustrated in the Security Assertion Markup Language (SAML) use case, demonstrating how single sign-on can be used to access web services.

Here is a quick video (w/o audio) demonstrating how to create an STS instance in OpenAM v.13 and then using Postman (REST client) to translate the tokenid of an authenticated user.

Caveat: There are obviously more configuration requirements for an actual deployment, the ACS URL would be key, for example. Refer to the STS documentation linked below the video.

References:

 

 

REST Requests:

Authenticate:

 POST /openam/json/authenticate HTTP/1.1
 Host: am.example.com:8080
 X-OpenAM-Username: username
 X-OpenAM-Password: password
 Content-Type: application/json
 Cache-Control: no-cache
{}

Translate:

 POST /openam/rest-sts/sts-test?_action=translate HTTP/1.1
 Host: am.example.com:8080
 Content-Type: application/json
 Cache-Control: no-cache
{
 “input_token_state”: {
 “token_type”: “OPENAM”,
 “session_id”: “AQIC5wM2LY4SfczD8y5-kVgiXY7rxxxxxxxxx8k0o8.*AAJTSQACMDEAAlNLABQtNjY4MzQxNjkzMDg2ODI1MjIzOQACUzEAAA..*”
 },
 “output_token_state”: {
 “token_type”: “SAML2”,
 “subject_confirmation”: “BEARER”
 }
 }

Next Steps?
We implement solutions like this for our clients nearly every day. Are you looking for assistance on a current project? Maybe you have a future project and you just want to keep in touch. Awesome! Head on over to our contact page and drop us a line. We’re looking forward to hearing from you.

MySQL As Credential Repository in ForgeRock OpenAM 13

$
0
0

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

If it perplexes you the difference between an Identity Repository and an Authentication Repository (a.k.a Credential Repository) in ForgeRock OpenAM, maybe the video tutorial on this post can render some hint. It’s basic, so shouldn’t be difficult to understand, if you don’t know it already. Before getting to the video, let me mention here a couple of points:

OpenAM has the following repositories:
Configuration Repository where the OpenAM Configuration Data is stored
Identity Repository where the User Profiles are stored
Authentication Repository or Credential Repository used by the ForgeRock to validate a User Credential
In the demonstration that follows, OpenAM connects to a MySQL Database for authenticating a User (Credential/Authentication Repository) and pulls up the User’s profile from an embedded OpenDJ instance (Identity Repository). If the User’s profile does not exist in the Identity Repository, OpenAM dynamically creates it.

Now on to the video. Enjoy!

Viewing all 66 articles
Browse latest View live