OpenAM: a Java access management server with policy agents and pluggable auth

One server for authentication, SSO, authorization and federation

OpenAM is described as an access management solution that includes Authentication, SSO, Authorization, Federation, Entitlements and Web Services Security, and the point of bundling all of that is interoperability with things that already exist. The README says it plainly: CDSSO, SAML 2.0, OAuth 2.0 and OpenID Connect ensure that OpenAM integrates with legacy, custom and cloud applications without requiring modifications to them. That last clause is the design constraint behind the whole product, because a scheme that protected modern applications but forced changes into a mainframe-hosted application would have a much smaller audience. The framing is ownership rather than feature comparison, since the README calls it a developer-friendly, open-source control solution that lets you own and protect your users' digital identities. It is aimed at platform and security engineers in organisations with a fleet of internal applications and a need to centralise policy across them.

Authentication is a chain you can extend with your own module

The authentication story is built in layers. OpenAM can set up complex authentication processes using several methods, including login and password, OTP, a saved cookie, QR authentication and more, and it can delegate to third-party identity providers over SAML, OAuth2, NTLM and Kerberos. The extensibility claim is specific rather than vague, because the pluggable architecture lets you implement a custom authentication module, a user data source, a session data source and post-authentication process logic. Those four extension points are the ones that matter in practice. A user data source is how a directory or a database becomes the identity store. A custom authentication module is how you plug in a device check or a risk score. Post-authentication process logic is where you decide what happens next, and session data sources decide where session state lives. For a team that has to answer a security questionnaire, this is the part that matters, and the README does not document the internal interfaces in detail, so the wiki and the module sources are where you would look.

Access decisions are policies evaluated beside your resources

Authorization is handled by policy rather than by code in each application, and there are three named styles. Access can be role-based, authentication level-based, or attribute-based, and when those are not enough you can script access policy. The enforcement point is a policy agent, and the README lists the family of them. OpenIG acts as a gateway, reverse proxy and authorization endpoint, and there are agents for Java, for .Net and Mono, and a web agent for Apache 2.2 and 2.4 on x64 and for IIS on Windows in x32 and x64. The design consequence is that the application is protected by something in front of it, usually OpenIG, which means the application itself does not need to know about tokens or policy evaluation. The cost is that you now operate a component in front of every protected application, and the README does not document how those agents are upgraded or rolled back across a fleet.

Federation in both directions, plus cross domain SSO

OpenAM can act as both an Identity Provider and a Service Provider, which is the configuration most organisations end up with eventually. The federation protocols it speaks are OAuth2 and OpenID Connect on one side and SAMLv2 on the other, and the README also lists SAML 2.0, OAuth 2.0 and OpenID Connect among the protocols that let it integrate with existing applications. Cross Domain Single Sign-On is the feature that ties the deployment together, since after a single authentication a user gets access to all resources protected by OpenAM and there is no need to authenticate again at other services. For a multi-application estate this is the difference between one login prompt and one prompt per application, and it is why the agents and the federation configuration have to be designed together rather than deployed one application at a time.

Building and running it from source on a JDK

The build is Maven based and expects JDK 11 or higher. On Windows there is one preparatory step, because long paths need enabling before you clone:

git config --system core.longpaths true

Then the clone and the build:

git clone https://github.com/OpenIdentityPlatform/OpenAM.git
mvn install -f OpenAM

Running it needs a fully qualified host name in the hosts file, since the console and the login endpoints are addressed by name rather than by address:

127.0.0.1 login.domain.com

With that in place the server starts from the source tree and the console is then reachable at the openam path on port 8080:

mvn cargo:run -f OpenAM/openam-server

For most people, though, the practical entry point is the prebuilt distribution package or the Docker image rather than a local build.

A long list of Maven modules, and what they tell you

The top level of the repository is a list of Maven modules, and reading it is the fastest way to understand the scope. The core sits in openam-core, with openam-common, openam-shared, openam-schema, openam-i18n and openam-audit around it. The functional pieces are separated cleanly, with openam-authentication, openam-federation, openam-oauth2, openam-oauth2-saml2, openam-entitlements, openam-radius and openam-sts as separate modules rather than one large server module. There are token modules, openam-tokens and openam-coretoken, and a scripting module, openam-scripting, which is where the scripted access policy policy runs. Client and integration surfaces are separate too, with openam-rest, openam-core-rest, openam-clientsdk and openam-http-client. Two module names stand out for a reader with a modern eye, openam-mcp-server, which is a Model Context Protocol server, and openam-time-travel, alongside openam-notifications-websocket, openam-push-notification and openam-dashboard. The build and deploy badges at the top of the README point at GitHub Actions workflows for both, and the tree also carries end-to-end tests, examples, test utilities and a checkstyle configuration.

CDDL licensing, a 16.x line and where support comes from

The licence is the Common Development and Distribution License, which GitHub cannot classify into its standard buckets, so the licence field on the repository says a custom licence that GitHub cannot classify, and the project points to the LICENSE file for the authoritative text. That is the one place to read carefully if you are embedding OpenAM, because CDDL is file level copyleft rather than the permissive Apache 2.0, and the difference decides what you can ship. On versions, the releases are 16.1.1 on 2026-06-17, 16.1.2 on 2026-07-20 and 16.1.3 on 2026-09-18, and the last push was on 2026-10-19 with the repository not archived, so the 16.1 line is where current work lands. Distribution comes as packages for all operating systems and as a Docker image under openidentityplatform/openam. Support is community documentation, discussions and issues, with a separate approved vendor list for commercial support, and the project accepts sponsorship and contributions through OpenCollective. Its lineage is acknowledged in the README, tracing back to Sun Access Manager and OpenSSO, Oracle OpenSSO and the Forgerock OpenAM fork.

Editorial conclusion

OpenAM fits an organisation that already runs Java infrastructure, needs OpenAM to sit in front of legacy applications as well as cloud ones, and wants to write its own authentication module or scripted access policy rather than configure what a hosted identity provider offers. It does not fit a small team that only needs OIDC for one application, since the deployment surface includes a policy agent per protected application plus a FQDN and a JRE, and it does not fit a codebase that requires a permissive licence, since the project is distributed under the CDDL rather than Apache 2.0. Before you adopt it, read LICENSE.md to see what the copyleft scope covers for your build, then verify in a test deployment that the authentication chain and the policy agents behave the way your existing applications expect before pointing production traffic at it.

Frequently asked questions

Official sources

1. Issues
2. OpenIdentityPlatform/OpenAM on GitHub
3. Project website
4. README
5. Releases