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

ForgeRock OpenIDM 4 uses OrientDB as its default datastore, which is good for learning and evaluation, but not suitable for a Production environment. In an earlier post on this space, we looked at the Configuration of MySQL database as the repository for OpenIDM 4. Picking up from there, because a site that I know of uses PostgreSQL instead of MySQL, made a quick demonstration on setting up OpenIDM 4 with PostgreSQL.

Enjoy!

Related ForgeRock Documentation:
Setting up OpenIDM with PostgreSQL

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!

Yesterday, I’ve talked about the most important change in OpenDJ 3.0, that is the new PDB Backend. Let me detail other new and improved features of OpenDJ 3.0, still related to backends and replication.

As part of the work for the new backend, we’ve worked on the import process, in order to make it more I/O efficient and thus faster.

Here’s some numbers, importing 1 000 000 users in OpenDJ.

In OpenDJ 2.6.3:

$ import-ldif -l ../1M.ldif -n userRoot
[03/Feb/2016:15:41:42 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381717 msg=Installation Directory: /Space/Tests/Blog/2.6/opendj
...
[03/Feb/2016:15:42:54 +0100] category=JEB severity=NOTICE msgID=8847454 msg=Processed 1000002 entries, imported 1000002, skipped 0, rejected 0 and migrated 0 in 71 seconds (average rate 13952.5/sec)

In OpenDJ 3.0, with the JE Backend:

$ import-ldif -l ../../1M.ldif -n userRoot
[03/02/2016:15:45:19 +0100] category=UTIL seq=0 severity=INFO msg=Installation Directory: /Space/Tests/Blog/3.0/opendj
...
[03/02/2016:15:46:22 +0100] category=PLUGGABLE seq=74 severity=INFO msg=Processed 1000002 entries, imported 1000002, skipped 0, rejected 0 and migrated 0 in 62 seconds (average rate 15961.2/sec)

In OpenDJ 3.0, with the PDB Backend

$ import-ldif -l ../../1M.ldif -n userRoot
[03/02/2016:15:59:38 +0100] category=UTIL seq=0 severity=INFO msg=Installation Directory: /Space/Tests/Blog/3.0/opendj
...
[03/02/2016:16:00:38 +0100] category=PLUGGABLE seq=48 severity=INFO msg=Processed 1000002 entries, imported 1000002, skipped 0, rejected 0 and migrated 0 in 58 seconds (average rate 17038.7/sec)

We’ve also completely reworked the storage layer for the replication changes, moving away from the BDB JE database. Instead, we’re using direct files, again providing much smaller disk occupancy (and thus optimising I/Os) but also allowing much more efficient purging of old data.

As part of these changes, we’ve made serious improvements to the way the replication changes can be read and searched using LDAP under the “cn=Changelog” suffix. More importantly, we’ve now have a way to ensure a complete ordering of the changes published, and thus consistency of their “changeNumbers”. That is to say that now, when reading “cn=Changelog” on different replicated servers, the change with “ChangeNumber=N” will be the same on all servers, allowing applications that read these changes to failover from one server to another. We’ve added a way to resynchronise these ChangeNumbers when adding a new replica to an existing topology, or when restoring one after a maintenance period.

Still on the subject of the ChangeLog, we’ve added another level of security to it, by introducing a “changelog-read” privilege that provides a better control on which applications and users are allowed to read the data from the “cn=Changelog” suffix.

That’s all for today. Tomorrow, I will continue with all the other new features and enhancements in OpenDJ 3.0.

If you have done it yet, you can download OpenDJ 3.0 from ForgeRock’s BackStage and start playing with it. And check the Release Notes for more information.

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.

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

Github

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

A few months back, I had published a post with a video demonstration on setting up Email in now older version of ForgeRock OpenIDM. If you haven’t seen it and would like to take a look at it, it’s here. Between now and then a lot of things changed, one of which is an improved UI in the recently released OpenIDM 4. If you’ve four minutes to spare, watch the video below to see how good a work has gone into the OpenIDM 4 UI improvement.

Enjoy!

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.3
• 12.0.1
• 12.0.2

Customers can obtain these patch bundles from BackStage.

Issue #201601-01: Open Redirect

Product: OpenAM
Affected versions: 9.5.5, 10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only, DAS
Severity: Critical

Due to a bug in the goto URL validation system it was possible to perform Open Redirect attacks by sending the end-users to specially constructed URLs that were considered valid by the goto URL validator.

Workaround:
Enable the XUI, which is not vulnerable to this issue.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-02: Potential Denial of Service attack in multi-site deployments

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

Multi-site deployments of OpenAM which share the same load-balancer are vulnerable to a Denial of Service attack using carefully crafted requests.

Workaround:
Configure load-balancers to only route requests for a single site and not to re-route any requests for a different site.

Resolution:
Deploy the workaround or update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-03: Cross Site Scripting

Product: OpenAM
Affected versions: see below
Fixed versions: 13.0.0
Component: see below
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/federation/* (Core Server)
/openam/saml2/jsp/exportmetadata.jsp (Core Server, Server Only)
/openam/WSFederationServlet/metaAlias (Core Server, Server Only)
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/OAuthLogout.jsp (Core Server, Server Only)

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:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-04: Open Redirect

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
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

The following obsolete ID-FF federation endpoints did not correctly validate redirect URLs allowing an attacker to redirect an end-user to a site they control:
/openam/consentHandler
/openam/federation

Workaround:
Block access to the listed endpoints with the container (for example using the mod_security Apache module) or filter external requests until a patch is deployed.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-05: Business Logic Vulnerability

Product: OpenAM
Affected versions: 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If more than one realm is configured in OpenAM it is possible for a user in one realm to generate security tokens for a different realm via the REST STS.

Workaround:
Block access to the following URI:
/openam/rest-sts/*

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-06: Business Logic Vulnerability

Product: OpenAM
Affected versions: 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If more than one realm is configured in OpenAM it is possible for an OAuth2 client in one realm to obtain an OAuth2 access_token for a different realm.

Workaround:
Block access to the following URI:
/openam/oauth2/access_token

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-07: Open Email Relay

Product: OpenAM
Affected versions: 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If the self-service interfaces are enabled it is possible for an attacker to send email using the configured email server.

Workaround:
Disable all user self-service interfaces in Configuration > Global > User Self Service and for any realms you have enabled it for in [realm] > Services > User Self Service.

Resolution:
Important Note:
This is a backwards-incompatible change, the forgotPassword and register actions are now utilizing localized messages defined in RestSecurity.properties. To define different subjects and messages per realm, please utilize the new “Localization Bundle” setting in the User Self Service service.
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-08: Previous Administrator Password Still Valid

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
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

After changing the administrator (amAdmin) password it is possible to log in using the old password until the new password has been used once.

Workaround:
After changing the administrator password, log in once using the new password on each server in the deployment or restart all servers.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-09: Insufficient Authorization

Product: OpenAM
Affected versions: 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If the Device ID Match/Save modules are used, it is possible for an attacker to access saved device profiles for another user and use them to spoof that user’s device.

Workaround:
Block access to the following endpoint:
/openam/json/users/*/devices/trusted/
Where * should match any user id.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle. If you believe that a user’s device profiles may have been compromised then you should disable Device ID Match modules.

Issue #201601-10: Information Leakage

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
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

It is possible to obtain information about which accounts exist on the system by sending carefully crafted requests to the following endpoints:
/openam/json/authenticate
/openam/identity/authenticate
/openam/identity/xml/authenticate
/openam/identity/json/authenticate

Workaround:
Block access to the following endpoints:
/openam/json/authenticate
/openam/identity/authenticate
/openam/identity/xml/authenticate
/openam/identity/json/authenticate

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-11: Open Redirect

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
Fixed versions: 13.0.0
Component: Core Server, Server Only, DAS
Severity: Medium

If relative goto URLs are added to the redirect URL whitelist an attacker can use a carefully crafted URL to redirect end-users to a different destination.

Workaround:
Ensure that all whitelisted redirect resources are in absolute format, i.e. they have protocol scheme defined.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-12: OATH Replay Vulnerability

Product: OpenAM
Affected versions: 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

If OATH TOTP authentication is enabled an attacker who is able to intercept a TOTP code may be able to replay it within the same TOTP time step.

Workaround:
Disable OATH TOTP authentication or reduce the time step size to mitigate the vulnerability.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-13: Open Redirect

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
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

Using a carefully crafted request an attacker may be able to redirect an end-user to a non-validated redirect URL. The attacker must be able to set cookies in the same domain as OpenAM. The following endpoint is vulnerable:
/openam/cdcservlet

Workaround:
Block access to the following endpoint if you are not using CDSSO:
/openam/cdcservlet

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle

Issue #201601-14: Content Spoofing Vulnerability

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
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

Using a carefully crafted request an attacker can display plain text messages within the content of a valid page.

Workaround:
Block access to the following endpoints:
/openam/validatorFooter.jsp
/openam/validatorWait.jsp

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-15: Password Logging

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
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Low

If MESSAGE-level debug logging is enabled the SecurID module logs passwords in plain text.

Workaround:
Disable MESSAGE-level debug logging in all production environments.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

In the previous posts, I talked about the new PDB Backend in OpenDJ 3.0, and the other changes with backends, replication and the changelog.

In this last article about OpenDJ 3.0, I’m presenting the most important new features and enhancements in this major release:

Certificate Matching Rules.

OpenDJ now implements the CertificateExactMatch matching rule in compliance with “Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates” (RFC 4523) and implements the schema and the syntax for certificates, certificate lists  and certificate pairs.

It’s now possible to search a directory to find an entry with a specific certificate, using a filter such as below:

(userCertificate={ serialNumber 13233831500277100508, issuer rdnSequence:"CN=Babs Jensen,OU=Product Development,L=Cupertino,C=US" })

Password Storage Schemes

The PKCS5S2 Password Storage Scheme has been added to the list of supported storage schemes. While this one is less secure and flexible than PBKDF2, it allows some of our customers to migrate from systems that use the PKCS5S2 algorithm. Other password storage schemes have been enhanced to support arbitrary salt length and thus helping with other migrations (without requiring all users to have a new password).

Disk Space Monitoring.

In previous releases, each backend had a disk space monitoring function, regardless of the filesystems or disks used. In OpenDJ 3.0, we’ve created a disk space monitoring service, and backends, replication, log services register to it. This allows the server to optimise its resource consumption to monitor, as well as ensuring that all disks that contain writable data are monitored, and alerts raised when reaching some low threshold.

Improvements

There are many improvements in many areas of the server: in the REST to LDAP services and gateway, optimisations on indexes, dsconfig batch mode, DSML Gateway supporting SOAP 1.2, native packages… For the complete details, please read the Release Notes.

As always, the best way to really see and feel the difference is by downloading and installing the OpenDJ server, and playing with it. We’re providing a Zip installation, an RPM and a Debian Package, the DSML Gateway and the REST to LDAP Gateway as war files.

Over the course of the development of OpenDJ 3.0, we’ve received many contributions, in form of code, issues raised in our JIRA, documentation… We address our deepest thanks to all the contributors and developers :

Auke Schrijnen, Ayami Tyndal, Brad Tumy, Bruno Lavit, Bernhard Thalmayr, Carole Forel, Chris Clifton, Chris Drake, Chris Ridd, Christian Ohr, Christophe Sovant, Cyril Grosjean, Darin Perusich, David Goldsmith, Dennis Demarco, Edan Idzerda, Fabio Pistolesi, Gaétan Boismal, Gary Williams, Gene Hirayama, Hakon Steinø, Ian Packer, Jaak Pruulmann-Vengerfeldt, James Phillpotts, Jeff Blaine, Jean-Noël Rouvignac, Jens Elkner, Jonathan Thomas, Kevin Fahy, Lana Frost, Lee Trujillo, Li Run, Ludovic Poitou, Manuel Gaupp, Mark Craig, Mark De Reeper, Markus Schulz, Matthew Swift, Matt Miller, Muzzol Oliba, Nicolas Capponi, Nicolas Labrot, Ondrej Fuchsik, Patrick Diligent, Peter Major, Quentin Cassel, Richard Kolb, Robert Wapshott, Sébastien Bertholet, Shariq Faruqi, Stein Myrseth, Sunil Raju, Tomasz Jędrzejewski, Travis Papp, Tsoi Hong, Violette Roche-Montané, Wajih Ahmed, Warren Strange, Yannick Lecaillez. (I’m sorry if I missed anyone…)

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"

}

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

If you haven’t gotten started with the newer version of ForgeRock OpenIG, the following Video might be of some help. I’ve done this before, but using now an older version of the Product. So if you are familiar with that, then this gives you an assurance that everything continues to work as before, and that there is more to it (that’s a story for another day though). So if you haven’t gotten your hands dirty with ForgeRock’s Identity Gateway solution, I invite you to have a look at it, and everything that you may need to get started with it, you will find it in the video below.

Very quickly, let me tell what’s done in the Screen-cast:

– Install Jetty
– Deploy ForgeRock OpenIG in Jetty
– Install Minimal HTTP Server
– Configure ForgeRock OpenIG to post user Credentials to the HTTP Server to return a User Profile Page (so the authentication process is transparent to the user.

Please note that the practice of hard-coding the User Credential is something that you’ll probably never see in a real world scenario, but of course the intent here is only to get a rough idea of what the OpenIG can do. The illustration below might give you a decent idea on the flow:

The video, I’m confident, will make it more clear.Enjoy!

Related Documentation/Video:
– ForgeRock OpenIG Documentation
– ForgeRock OpenIG (3.x) Installation and Configuration in a Linux Container

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

If we’ve just moved ahead of ‘Getting Started with OpenIG 4‘, the following screen-cast might of some interest. In fact, this is a remake of a video that’s posted here, which was based on now older version of ForgeRock OpenIG.

So what’s in the video here? We’ve a CSV file with some User details. A user tries to access a URI, which hits OpenIG, who by using some Route Configuration files, looks up User Credentials from the CSV file and posts it to the HTTP Server, to get a User Profile Page (Post Authentication Landing Page) in return. So the Client, without having to go through the inconvenience of supplying his/her User Credentials, gets the Post Authentication Landing Page from the HTTP Server. See, if my attempt to capture the flow below makes sense.

If that didn’t make your life easy, hopefully the demonstration in the video will. Enjoy!

Related Documentation/ Video:
– ForgeRock OpenIG Documentation
– ForgeRock OpenIG 3.x – Getting Credentials from File Datastore

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

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

To know how ForgeRock OpenIG 4 is configured to fetch User Credentials from a Database for User Authentication (a process transparent to the User), the following Video log might help. I had posted a similar video on this space earlier, but that then the User Credentials were fetched from a Flat File (CSV). The flow isn’t quite different from that, just that a Filter used by ForgeRock OpenIG in this case is different and that we should configure the OpenIG to connect to the DB.

In the video, we’ll:
– Install the H2 Database. Create ‘Users’ table and load User data in it
– Configure OpenIG (deployed in Jetty) to connect to the Database
– Prepare OpenIG Route Configuration file to fetch User Credentials (based on a Email address) and post the data to HTTP Server, who responds with the User profile page

For those whose right side of the brain is more prominent, here’s the visual representation of what is mentioned above:

For those who don’t want to think too much looking at the illustration below, but would like to sit back, relax and enjoy watching a show, here’s the video. Enjoy!

Related Documentation/Video
– ForgeRock OpenIG Documentation
– Screencast on using OpenIG 3.x to Connect to a JDBC Datastore

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:

January’s release of the ForgeRock Identity Platform includes OpenIG 4. This release brings new API gateway features, better integration with OpenAM, extended support for standards, and increased performance.

OpenIG 4’s new audit framework now handles audit events in a common way across the whole ForgeRock platform. For example, OpenIG 4 can track interactions across OpenAM, OpenDJ, and OpenIDM. Audit logs can be centralized and transactions can be traced across the platform. Additionally, the audit framework supports logging to files, databases, and the UNIX system log.

Improved monitoring data for the servers, applications, and APIs provides a better view of how OpenIG 4 and its routes are used. Delivered through REST endpoints, data includes request and response statistics, such as the number of requests, time to respond, and throughput.

The new throttling feature limits access to applications and APIs, increasing security and fairness. Throttling can enforce flexible rate limits for a variety of use cases, such as to limit the number of requests per minute from clients at the same network address.

Several new features improve integration with OpenAM:

• A new policy enforcement filter allows only authorized access to protected resources. You can now use OpenIG instead of an OpenAM agent for authorization, and centralize all your access control policies in OpenAM.
• SSO and federation for applications has been extended by a token transformation filter to use with the OpenAM REST Security Token Service. By using the filter, a mobile app with an OpenID Connect token can now access resources held by a federated service provider.
• A new password replay filter simplifies the configuration for replaying credentials in common use cases.

Support for standards has been extended:

• OpenID Connect Discovery makes it possible for users themselves, instead of system administrators, to select identity providers.
• Initial support is available for a User Managed Access resource server, where users can control who accesses their resources, when, and under what conditions.

Behind the scenes, OpenIG 4 internals have been refactored to improve scalability - because we are no longer blocking threads, a single deployment can handle more requests at the same time.

These are just some of the changes in OpenIG 4. Check the Release Notes for a full list of what’s new in this release, and download the software from ForgeRock’s BackStage.

We love your feedback. Please feel free to ask questions, make suggestions, and tell us what you think of OpenIG by joining the community and getting on the forum and mailing list.

Note: If you happened to notice that my english has noticeably improved in this post, there is a reason :) I therefore would like to give full credits to Joanne, our new tech writer, who wrote all of this.

This blog post was first published @ sauthieg.github.io, included here with permission.

January’s release of the ForgeRock Identity Platform includes OpenIG 4. This release brings new API gateway features, better integration with OpenAM, extended support for standards, and increased performance.

OpenIG 4’s new audit framework now handles audit events in a common way across the whole ForgeRock platform. For example, OpenIG 4 can track interactions across OpenAM, OpenDJ, and OpenIDM. Audit logs can be centralized and transactions can be traced across the platform. Additionally, the audit framework supports logging to files, databases, and the UNIX system log.

Improved monitoring data for the servers, applications, and APIs provides a better view of how OpenIG 4 and its routes are used. Delivered through REST endpoints, data includes request and response statistics, such as the number of requests, time to respond, and throughput.

The new throttling feature limits access to applications and APIs, increasing security and fairness. Throttling can enforce flexible rate limits for a variety of use cases, such as to limit the number of requests per minute from clients at the same network address.

Several new features improve integration with OpenAM:

• A new policy enforcement filter allows only authorized access to protected resources. You can now use OpenIG instead of an OpenAM agent for authorization, and centralize all your access control policies in OpenAM.
• SSO and federation for applications has been extended by a token transformation filter to use with the OpenAM REST Security Token Service. By using the filter, a mobile app with an OpenID Connect token can now access resources held by a federated service provider.
• A new password replay filter simplifies the configuration for replaying credentials in common use cases.

Support for standards has been extended:

• OpenID Connect Discovery makes it possible for users themselves, instead of system administrators, to select identity providers.
• Initial support is available for a User Managed Access resource server, where users can control who accesses their resources, when, and under what conditions.

Behind the scenes, OpenIG 4 internals have been refactored to improve scalability – because we are no longer blocking threads, a single deployment can handle more requests at the same time.

These are just some of the changes in OpenIG 4. Check the Release Notes for a full list of what’s new in this release, and download the software from ForgeRock’s BackStage.

We love your feedback. Please feel free to ask questions, make suggestions, and tell us what you think of OpenIG by joining the community and getting on the forum and mailing list.

Scripting Design

This section introduces Client side and Server side scripts in OpenAM 13. These can be glued together to create Scripted Authentication modules that serve to create powerful authentication workflows as shown later in the Examples section.

Client Side Script

Authentication modules can use Client Side scripts and Server Side scripts using either JavaScript or Groovy. Note that the use of a Client side script is optional. If there is a requirement to collect information from the user, or browser plugins, fonts, screen resolution of a device, or even geolocation then by all means use the Client side script to collect and return the data to the Server side script.

The collected data is returned in the clientScriptOutputData object. You can use the .split() method to pull the client side data and parse accordingly.

An example Client side script is shown below.

Server Side Script

The Server side script handles authentication and is the place to put authentication workflow business logic. The Server side script has access to clientScriptOutputData and OpenAM’s powerful Scripting API. This script must set the authentication state to either success of failed, for example:

An example of using Server side scripts is as follows:

Chaining Scripted Authentication in OpenAM

You would setup your scripted module similar to any other authentication module in OpenAM, such as:

In this particular example, I have required DataStore to be a requisite module, followed immediately by a Scripted module that requires the authenticated user’s userId. See the following code snippet:

This Server side script is written in Groovy. The script reads the username and password from Shared State – a protected and shared area in memory – and uses the credential to make REST-based Policy calls to another OpenAM server (which could be a central policy hub in your enterprise, for example).

Scripting API

HTTP Commons Framework

OpenAM 13 introduces the HTTP Commons Framework. The following packages are available to developers:

org.forgerock.http.protocol.* – Request, Cookie, Entity, Header, Headers, and Response objects

org.forgerock.util.promise.* – Promise objects that represent the result of an asynchronous task in OpenAM

groovy.json.JsonSlurper – a very useful JSON parser that can be used in the scripts.

The API documentation is at http://commons.forgerock.org/bom/apidocs/index.html
You can use the new HTTP Commons Framework to create a new Request, and invoke REST API calls from the Server Side Script. For example: httpClient.send(Request), returns a Promise. Promise.get(), returns a Response. You may then parse the Response using JsonSlurper. The Server side script can access the Authentication State via the authState, and sharedState objects, as mentioned earlier.

Note that you will need to add the JsonSlurper, or any other class you wish to use, to the whitelist. Otherwise you will get a Security Exception stating use of the class is prohibited. You can whitelist a class using instructions documented here:

https://backstage.forgerock.com/#!/docs/openam/12.0.0/dev-guide/chap-scripted-auth-module#scripted-auth-module-sandbox

Logging

The logger object provides error(), message() and warning() methods for logging requirements.

Entity Profile

You are able to access user, group or device profile data via the idRepository object that provides the getAttribute(), setAttribute() and addAttribute() methods.

Original Request

You can also access the original login request using the requestData object, that provides the getHeader(s) and getParameter(s) methods.

Examples

Included here are some examples of using the Scripting API.

SSOToken

You can acquire an ssoToken object over REST

Policy Evaluation

Given the following two policies:

AuthnPolicy:

and AuthnPolicyY:

You can evaluate policy for the resource “authn/self’ and “authn/view”.

A policy decision is returned:

Check the policy decision and permit authentication if requested actions are ALLOWED:

Finally, logout the service account used for policy invocation using another REST call:

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:

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‘

Back on January 22nd, ForgeRock changed the world (well it certainly changed for me!). We released the update to the entire catalog of ForgeRock offerings – as well as a nomenclature change. For years, I’ve been the Product Manager for ForgeRock’s OpenIDM. Now, I’m the Product Manager for ForgeRock’s Identity Management Solution.

You’re probably saying “Sounds like a bunch of marketing to me…” -and on the one hand, you wouldn’t be wrong. However, we want people to think in terms of the functionality they need from the ForgeRock Platform rather than any features of a specific product. In this way – we can ensure that people are open to discussing requirements and we can look at fulfilling requirements rather than trying to get you to install this product or that.

So what does this release provide that’s new in terms of Identity Management and Provisioning functionality? Let me provide you with a short list and we can discuss the items you’re interested in with the comments section of the forum.

First off – UI: there’s a new, bootstrap based UI model that includes dashboards, widgets, theming, expanded extensibility and more. We also separated all Administrative functionality and put it in the Admin UI, while placing all self-service capabilities under what we call (obviously) the Self-Service portal.
As a sub point to the new Self-Service portal, we have a new (Self-Service) Registration, Password Reset and Forgotten User Name experience that’s configurable – and common across the ForgeRock platform. I know this will generate a lot of interest, so if you’d like to learn more, let me know!

Second – Roles and Relationships: We created and utilized the new intrinsic Relationship model to expand on our Role model and functionality. That means there is reverse relationship behind the Role model we have in Identity Management – and (like most things in the Identity Management area) it’s configurable and extensible to fit most any situation: Parent<->Child, Owner<->Device, User<->Group, Thing<->Sensor – whatever you can think of (and you’re not limited to one relationship… you can model whatever use case you may need)! Roles also are fully managed from the Admin UI – that mean Create, Read, Update, Delete (and more) are able to done visually from the UI (and of course from API/REST based interfaces).

Third – Mutli-Account Linking: Have you had to maintain separate accounts for users because they have different personas (like Administrators AND regular User, or multiple bank accounts – but just one login). The new Linked Qualifier allows you to have multiple personas (and any specific policies or attributes for those personas) while maintaining a single user account in a resource (like a database, Active Directory, LDAP or whatever). Internally, we handle the reconciliation of the account and each persona specific value or policy.

Fourth – Passwords: Until we can get rid of them, they’re here to stay. Therefore, we make it easier to manage password with Multiple password policies (even conditional policy), Hashing (rather than encrypting) of passwords (and to be honest, any attribute you want hashed). Even authenticating using ForgeRock’s Access Management solution (we used to call this OpenAM) rather than intrinsic accounts.

Finally, there’s a new upgrade and patching framework that instructs and guides you through maintaining the Identity Management Solution. As you receive updates from support (in the form of patches) or the product team (in the form of product updates or upgrades), we have service oriented, or UI driven ways of informing what the change is, pausing (or more properly, putting into maintenance) Identity Management services, backing up the existing configuration and files, updating/upgrading the services, and reporting back all the changes that we made (while maintaining your old configuration and files). This makes managing the solution much easier and maintainable.

Of course there are lots more items I could talk about – Documentation has been updated (and several new guides are included), added support for repository technologies, ForgeRock commons audit, and of course connectors! This was just intended to give you a taste of what’s new in OpenIDM 4…err, the ForgeRock Identity Management Solution (give me a little time to adjust :^) )

You can find all of the newest releases at ForgeRock.com and ForgeRock.org!

Tim

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:

• OpenAM 13 Admin Guide – 17.2. Configuring the Security Token Service
• OpenAM 13 Developer’s Guide – 2.1.7. RESTful Secure Token Service

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.

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

As you know, the newer version of ForgeRock Directory Services is out. Based on the ForgeRock OpenDJ 3.0 documentation, here’s my video log (~3 minutes) on the OpenDJ upgrade process, which could be considered a resource to learn and evaluate the OpenDJ upgrade process. Needless to emphasize, an activity as Upgrade of a Production on a Production environment requires detailed Analysis and Planning before execution.

Related Documentation and other Useful Links:
– ForgeRock OpenDJ 3 Documentation – Upgrade
– Ludo’s Sketches: What’s new in OpenDJ 3 – Part I
– Ludo’s Sketches: What’s new in OpenDJ 3 – Part II
– Ludo’s Sketches: What’s new in OpenDJ 3 – Part III