How to protect your OpenAM deployment against clickjacking

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

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

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

How to configure OpenAM?

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

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

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

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

OpenAM Security Advisory #201604

Security vulnerabilities have been discovered in OpenAM components. These issues may be present in versions of OpenAM including 13.0.0, 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):

  • 11.0.3
  • 12.0.1
  • 12.0.2
  • 13.0.0

Customers can obtain these patch bundles from BackStage.

Issue #201604-01: User Impersonation via OAuth2 access tokens

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

A specific type of request to the /openam/oauth2/access_token endpoint can result in obtaining OAuth2 access token on behalf of any user in the current realm.

Workaround:
Ensure that com.sun.identity.saml.checkcert advanced server property is set to on (default) so that basic certificate validation is being carried out. Additionally, you must verify that the OpenAM keystore does not contain expired and/or untrusted certificates.

If unsure, block all access to the /openam/oauth2/access_token endpoint.

Resolution:
Deploy the relevant patch bundle. Note that as part of the resolution several additional checks have been implemented for the SAML2 OAuth2 grant. After installing a patch you will need to perform the following additional steps:

  • The issuer of the assertion must be configured as a remote IdP
  • The audience of the assertion must be configured as a hosted SP
  • The hosted SP and the remote IdP must be in the same Circle Of Trust
  • The assertion parameter value MUST be Base64url encoded

Issue #201604-02: 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, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: High

The following endpoint does not correctly validate redirect URLs allowing an attacker to redirect an end-user to a site they control:

  • /openam/idm/EndUser

Workaround:
Block all access to the /openam/idm/EndUser endpoint

Resolution:
Deploy the relevant patch bundle and ensure that at least one whitelist URL is defined for the redirection validation to be applied.

Issue #201604-03: 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, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only, DAS
Severity: High

OpenAM is vulnerable to cross-site scripting (XSS) attacks which could lead to session hijacking or phishing.
The following endpoint was found vulnerable:

  • /openam/cdcservlet

Workaround:
Block all access to the /openam/cdcservlet endpoint.

Resolution:
Deploy the relevant patch bundle.

Issue #201604-04: Insufficient Authorization

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

Due to insufficient authorization checks it is possible to modify arbitrary user attributes for a personal account when using the /json/users endpoint.

Workaround:
Disable the forgotten password feature in all realms:

  • Disable Forgot Password for Users under Legacy User Self Service service (13.0.0)
  • Disable Forgot Password for Users under User Self Service service (12.0.x)
  • Disable Forgot Password for Users under REST Security service (11.0.x)

Resolution:
Deploy the relevant patch bundle.

Issue #201604-05: Information Leakage via Account Lockout

Product: OpenAM
Affected versions: 13.0.0 (and versions with #201601 security patch applied)
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: Medium

OpenAM can leak information about password correctness even when OpenAM’s Account Lockout feature is enabled, allowing brute-force attackers to guess passwords for end-users.

Workaround:
Disable Account Lockout in OpenAM, and utilize the underlying Data Store’s account locking capabilities.

Resolution:
Deploy the relevant patch bundle.

Issue #201604-06: 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, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: Medium

OpenAM can leak details about the home directory of the user running the OpenAM container.

Workaround:
Remove the /openam/nowritewarning.jsp file from the OpenAM WAR file.

Resolution:
Deploy the relevant patch bundle and delete the nowritewarning.jsp file from the OpenAM deployment.

OpenAM Web Policy Agent Security Advisory #201603

A security vulnerability has been discovered in the OpenAM Web Policy Agent. This issue is present in version 4.0.0 of the OpenAM Web Policy Agent.

This advisory provides guidance on how to ensure your deployments can be secured. A workaround and a patch is available for the issue.

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

The recommendation is to deploy the following maintenance release of the Web Policy Agent (in accordance with ForgeRock’s Maintenance and Patch availability policy): 4.0.1

Customers can obtain this updated Web Agent version from BackStage.

Issue #201603-01: Business Logic Vulnerability

Product: OpenAM Web Policy Agent
Affected versions: 4.0.0
Fixed versions: 4.0.1
Component: Web Agent
Severity: Critical

Description:

When the Agent not enforced list contains a wildcard entry it may be possible to access any protected resource on the server without the need for authorization.

Workaround:

Set ‘com.sun.identity.agents.config.ignore.path.info.for.not.enforced.list’ to false and define explicit security rules for your website not-enforced resources.

Alternatively, set ‘com.forgerock.agents.notenforced.url.regex.enable’ to true and use regular expression based ‘not-enforced rules’ as per OpenAM Web Policy Agent User’s Guide › Configuring Web Policy Agents › Configuring Web Policy Agent Application Properties, instead of the older wildcard approach. Even so, explicit ‘not-enforced rules’ will need to be created.

However, it should be noted that neither of these workarounds will work well with dynamic URLs. In this instance, the only solution is to upgrade to the 4.0.1 Web Agent Release.

Resolution:

Use the workaround or deploy the relevant 4.0.1 Web Policy Agent Release.

OpenIDM Security Advisory #201602

Security vulnerabilities have been discovered in OpenIDM components. These issues are present in versions of OpenIDM including 3.x and 4.0.x.

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 High. Deployers should take steps as outlined in this advisory and deploy the recommended workarounds or resolutions as described within each issue below.

Issue #201602-01: Unencrypted Repo JDBC Password

Product: OpenIDM
Affected versions: 3.0.0, 3.1.0, 4.0.0
Fixed versions: n/a
Component: OpenIDM JDBC Repository Server
Severity: High

JDBC Repository passwords are no longer auto-encrypted by OpenIDM when the repository is activated. As a result, the password stored within the repository configuration as well as those written to the JSON configuration files (repo.jdbc.json or datasource.jdbc-default.json) and the OpenIDM log will appear in clear-text.

Workaround:
Manually encrypt the JDBC Repository password using the OpenIDM Command-Line Interface as detailed in the following Knowledge Article: Repository password is not encrypted in OpenIDM 3.x or 4.x log and configuration files.

Resolution:
None.

How to boost OAuth2 performance in OpenAM 13

One of the unfortunate issues with OpenAM 13 is that there is a performance problem when performing OAuth2 operations, more namely: OPENAM-8023. Whilst the underlying root cause appears to be a rather complex problem deep in the SMS framework, there is a quite simple, but very effective way to work around this issue.

You’ll need to run the following ssoadm commands for all the realms (where you are using OAuth2):

$ openam/bin/ssoadm add-svc-realm -e  -s ScriptingService -u amadmin -f .pass -D file
$ openam/bin/ssoadm create-sub-cfg -s ScriptingService -g scriptConfigurations -u amadmin -f .pass -D file -e 

Common sense: Please note that you only need to run these commands on versions that are affected by OPENAM-8023.

OpenAM Security Advisory #201601

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.

Installing WebSphere on Linux

In order to test/resolve certain WebSphere specific OpenAM bugs, I decided to install this lovely container on a brand new Ubuntu VM. Now I must tell, I’m slightly biased towards open source containers, as they tend to be actually usable and aren’t as overcomplicated as their enterprise competitors (yes I’m talking about you WebSphere and WebLogic). So keeping that in mind let’s see what kind of suffering does one have to go through to get to a running WebSphere instance. NB: this is mostly a rant, the mostly useful info can be found at the bottom of this post. :)

How not to do it

I started with searching for “download ibm websphere 8.5.0”, and after a few clicks I figured out a few things:

  • There are service packs for each release or something alike, and apparently 8.5.0.2 is the latest for 8.5.0
  • There is also a release called 8.5.5
  • According to Wikipedia 8.5.5 can run on Java 8 as well

Since I like shiny new things, and one can only hope that new is always better, I decided that I want to install 8.5.5. After visiting the 8.5.5 pages I had to realize that installing 8.5.5 has the prerequisite of having 8.5.0 installed (enterprise software, eh), so let’s go back to the 8.5.0.2 downloads again…
The descriptions of the downloads are rather dubious, so I ended up downloading the first downloadable thing, and hoped for the best. Of course at this point I didn’t even wonder why the hell I need to download 2.4 GiB worth of ZIP files for an application server…
So I have unzipped the 2 downloaded files and I had to conclude that simply put there is no binary file that you can actually run. It turns out that the files that I just got now, are files that can be utilized by an IBM Installation Manager (facepalm). Of course there is little to no information about whether all the IM versions are actually able to install all existing IBM software, but who knows, maybe I’ll get lucky.

Nope. The IBM Installation Manager doesn’t really allow you to install anything by default, you need to add repositories manually to get it working (why it doesn’t come with default set of repositories that allows installing anything is beyond me), so I end up trying to point IM towards my unzipped 8.5.0.2 files and it seems like it’s able to pick up that repository.config file just fine. Trying to install anything still yields the same error though about not having any repositories present or that the ones configured have nothing installable. Just great.
The problem must be that I’m using the wrong version of the IM, and maybe an older version will be able to work with my downloaded 8.5.0.2, right? So I start to look for an IM version that is recommended for 8.5.0.2, after some random Google hits I find a documentation that mentions 1.5.3 version of IM, and I’ll attempt to download it, but I hit a new problem now.

Apparently writing 64 bit software for Linux seems to be a difficult thing to do for IBM, and the only downloadable items are for 32 bit Linux and some very weird 64 bit platforms that I’ve never heard of before. Downloading the 32 bit version of IM and then installing the following packages on Ubuntu helped a little bit:

apt-get install lib32z1 libgcc1:i386

But even with this old version of IBM IM I’m unable to install 8.5.0.2. At this point I just start to search a lot more, and finally I get to the holy grail.

How to install WebSphere

Search for WebSphere Express Trial and go through some silly registration process then make sure you uncheck all options about contacting you and if you did everything right, you will get access to a WebSphere 8.5.5.8 installer (somehow downloading the Express does not have the prerequisite of installing 8.5.0, no comment).

Once installed using the IBM Installation Manager you should realize that the IBM JDK shipped with WebSphere is a 32 bit only application, so make sure you’ve ran the above apt-get command beforehand.

Create a custom profile

I still don’t really know what a profile is meant to be, but I had this strong urge to create one, as everything in WebSphere seems to rely on these things. So I came up with the following commands:

$ bin/manageprofiles.sh -create -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/default -profileName default -profilePath /opt/IBM/WebSphere/AppServer/profiles/default
$ bin/manageprofiles.sh -setDefaultName -profileName default

Making my profile the default one should mean that I don’t have to use the -profileName default all the time when interacting with the CLI, so hopefully that will make my life easier in the long run.

At this stage I should mention that if for some reason the profile creation just hangs and doesn’t want to finish at all, then apparently your problem is that your /bin/sh does not map to /bin/bash! I mean what the hell…

Using IBM JDK7

Foolishly I thought that a standalone IBM JDK7 can be utilized by WebSphere, but of course I couldn’t really get that to work (not sure how to make managesdk aware of an external JDK installation), so I had to follow the official guide of downloading a WebSphere specific IBM JDK7, and then I had to use the managesdk utility to ensure that my default profile will use IBM JDK7:

$ bin/managesdk.sh -setNewProfileDefault -sdkName 1.7_32

That’s it, after all this you should be able to run WebSphere with the following command:

$ bin/startServer.sh server1 # No idea where that server1 comes from

Once WebSphere is running you can access the admin console at http://localhost:9060/ibm/console (if you only enter localhost:9060 you will face an error message to be absolutely user friendly), and your applications should be theoretically under port 9080 (because who needs to be consistent with every other container and port 8080).

Next time I’ll blog about OpenAM instead, promise. :)

OpenDJ Security Advisory #201508

Two security vulnerabilities have been discovered in all released versions of OpenDJ.

This advisory provides guidance on how to ensure your deployments can be secured.  Workarounds or patches are available for the issues, which will also be included in the forthcoming OpenDJ 2.6.4 maintenance release.

The severity of the issues in this advisory is Medium. Deployers should take steps as outlined in this advisory and apply the relevant update at the earliest opportunity.

The recommendation is to deploy the relevant patch or to upgrade to OpenDJ 2.6.4 when it becomes available.

Combined patches fixing all OpenDJ security advisories are available to customers for OpenDJ 2.6.0 – 2.6.3 from BackStage. Customers with other deployed patches should contact the support organization to obtain an updated patch. Customers running earlier releases need to upgrade. The fixes are also present in the community “trunk” nightly builds.

Issue #201508-01: LDAP read entry controls reveal protected attributes.
Product: OpenDJ
Affected versions: 2.4.0 – 2.4.6, 2.5.0-Xpress1, 2.6.0 – 2.6.3
Fixed versions: n/a
Component: Core Server
Severity: Medium

OpenDJ supports controls allowing an LDAP user to read and return the target entry of an update operation as part of the update operation itself. If the update operation succeeds, the target entry attributes should be returned subject to access control checks. These access control checks were not performed by OpenDJ, and the server would incorrectly return any attribute from the target entry.

The vulnerability can be exploited if the LDAP user performing the update has all of the following:

  • allowed access to use either the 1.3.6.1.1.13.1 or 1.3.6.1.1.13.2 controls;
  • allowed access to update (add/modify/delete/rename) an entry;
  • denied access to reading certain attributes on the entry being updated.

By default the impact is low because in OpenDJ anonymous users may not use these controls. By default authenticated users may only update their own entries, and anonymous users are read-only. By default users are prevented from reading only a few operational attributes from their own entry.

Customers with customized access control policies may wish to review them with ForgeRock support.

Workaround:

To prevent the vulnerability from being exploited, a simple solution is to temporarily restrict permission to use the two controls to trusted users until the patch is deployed. Ideally this would be done using the dsconfig command to identify the global ACI that allows the use of the two controls, and to then remove those two controls from that ACI’s targetcontrol list. Instructions for using dsconfig are in the OpenDJ Administration Guide.

A simple alternative would be to temporarily restrict the use of controls to RootDN users using the following ldapmodify command. Replace the parameters in italics:

ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j passwd.txt
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetcontrol="1.3.6.1.1.13.1 || 1.3.6.1.1.13.2")
 (version 3.0; acl "ForgeRock Security advisory 201508";
 deny(read) userdn="ldap:///anyone";)
-

Note: These controls are rarely used but you must test your applications to make sure they will not be affected. OpenAM does not use these controls and will not be affected. OpenDJ’s REST interfaces use these controls if the “readOnUpdatePolicy” configuration for an endpoint is set to “controls”.

Resolution:

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

Issue #201508-02: OpenDJ Administration Connector doesn’t reject anonymous operations.
Product: OpenDJ
Affected versions: 2.4.0 – 2.4.6, 2.5.0-Xpress1, 2.6.0 – 2.6.3
Fixed versions: n/a
Component: Core Server
Severity: Medium

OpenDJ has a global configuration parameter called “reject-unauthenticated-requests” that can be set to disallow any non-authenticated request. This provides an additional layer of protection in the server in addition to the normal access control protection. This parameter is used on any LDAP and LDAPS connection handlers (e.g. on port 389 and 636) however it was not used on the administration connector interface, which is typically on port 4444.

The parameter is set to “false” by default.

The bug’s impact is low, as access controls should always be used to enforce basic security and restrict the ability of non-authenticated connections to read or modify data.

Workaround:

Access controls should always be used to limit the data that non-authenticated connections can access. System-level firewall rules could be used to restrict access to the administration connector from only selected systems.

Resolution:

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

How to configure social authentication with LinkedIn

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

OpenAM Security Advisory #201507

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.