Skip to end of metadata
Go to start of metadata

Is there something that you always wished OpenAM would do or perhaps do differently. This page is intended as a initial open idea pages for new features and changes. Popular and useful changes will be promoted as an RFE and implemented in the normal way.




Full auto install

Currently the sso configuration tool must be run after the OpenAM war file is deployed. The war file could contain a site/server map file that allows for the deployment to happen silently and automatically. Thought needs to be given as to whether we need primary/slave mode or have a "smart" host that determines if initial configuration deploy has been completed. Primary/slave model is probably a good starting point.

Auto service deployment

Only custom services exist outside of the war file. For customers with custom services (such as a custom authentication module) these should be included in the war file in a specified location. The AMSetupServlet can then insert them into the configuration repository alongside the default service definitions.

Auto configuration deployment

A mechanism to remove the requirement to run a ssoadm command batch externally. This could be run as part of the primary install to pre-configure the environment.

Rapid Realm configuration import/export

This feature could be used in conjunction with the above request. A way in the GUI/CLI to dump realm config and fast import. This would save the customer from having to deal with LDAP directly.

Bundle OpenAM container

Ship OpenAM inside a container, eliminating the need to install a container for evaluation, for testing, and even for production deployments.




Pre Login Plug-in

The developer cannot pre-configure the session before authentication begins. The current plug-in is only called when the authentication process finished.

Complete AMLoginModule updates

Expose more functionality to the module such as account lockout and session quota.

Move UI away from JATO

The authentication user interface uses JATO and is unpleasant to customised from a behavioural perspective. Authentication UI should move to using faces allowing developers to better customise the authentication UI.

Fix REST web service to use Full Auth API

The RESTful authentication API should expose all AuthContext functionality around realm/service login and complex chains. The response should be in JSON.




Review of the privileges functionality

There is a lot of complexity in this part of the product and customers use of this functionality is patchy. Also it was using the policy framework and unsure if they have moved across to storing this information in the entitlements system. This area of the product should be reviewed.




Workflow Plugin API for Policy approvals

Integrate with ForgeRock OpenESB to control policy approvals.

Session Service



Replacing the session fail-over system with a new internal mechanism

The session failover system relies on the JMQ product and introduces a great deal of external complexity outside of the OpenAM deployment. The OpenAM deployment should manage its own session and federation context failover internally. Failover should be auto configured when a site is created and be transparent to the users and administrator.

Policy Agents



Policy Agent Monitoring

The policy agents either directly or via OpenAM should advertise monitoring information via JMX/SNMP. The policy agent operational status and statistics should be visible via these interfaces.

Updated policy agents

Current policy agents are getting outdated as new version of applications servers are being release, e.g. Tomcat 6, Websphere 8, ...




New Federation flows

Introduce new a wizard to allow rapid integration for Service Providers. Rather than have a separate wizard for each IDP, a single wizard where the Service Provider can select their IDP and then are guided through the integration wizard.

IDP Proxy using heterogenous protocols

Provide a IDP proxy in front of the multi-protocol hub to allow heterogenous federations to be proxyed through the product. Investigation into the suitability of WS-Federation must be performed.

IDP Proxy selector plug-in

Greater functionality around IDP selection with in the IDP proxy should be provided. A plugable mechanism that delegates to a customisable page.

Addition of OpenFM as php Fedlet

A Fedlet PHP Wizard in the console similar to the other Fedlet wizard.




Moving all functionality across to the new web console

The current beta console only manages Entitlements, Federation and Web Services Security. The remainder of the console functionality should be migrated across.

Sanitize Logging infrastructure

The current logging framework(s) are a mess: Their API is abysmal, its extensibility with alternative backends is not easy (seeing how the fedlet tries to achive this), looking at the code I'd guess performance also to be substandard. Also the extensive localization of even technical log messages is an unnecessary burden. At alternative logging frameworks exist that would easily replicate functions such as remote logging, while being more accessible, maintainable, performant. Improving the logging infrastructure seems like an important first step in confronting the abysmal quality of actual log output.




Traps (JMX Events)

The OpenAM monitoring framework should be able to set thresholds on the monitor able areas and send JMX events appropriately.

Project Maintenance and extensions



Move to Maven

Should we move away from ant and to maven? Pro's and Con's. Discuss.

Added: Yes PLEASE! Ant is a significant barrier, especially given absence prereq documentation (near as I can tell).

Added: Discuss where? How? Right here?

IDE Development support

Need to provide startup projects for OpenSSO components for all the common IDEs.

ForgeRock to host a Maven Repository

For maven users, a public repository that contains the OpenAM SDK and client SDK jar files would be very useful to the community.

Continuous Integration with Hudson

improve the development with CI features like automatic testing, report-generating, and maven artifact deploying

Smaller/faster full download

The full OpenAM download is so large and slow that it is easy to forget why one started to download in the first place. It would be nice to have a full download (tools, customizable .war, samples) an order of magnitude smaller.




Not just RBAC.

U.S. DoD needs more advanced authorization models than RBAC esp. ABAC and PBAC. Documentation leaves state of XACML unclear. Not clear how users can help to add anything that's missing or to get support while doing so. Something like Sun's IRC or mailing lists perhaps?



  • No labels


  1. Unknown User (avallen)

    Regarding the wishlist itme "move to maven" I'd like to advise you to not use maven as the build tool and instead evaluate "gradle" which would provide a much easier upgrade path for the existing ant-based setup, while being compatible with maven's dependency resolution and repository infrastructure that many have come to love.

    Also gradle would be a good tool for other build-unrelated automation and configuration tasks.

    In contrast to a migration to Maven, one from Ant to Gradle can be rather painless. Just start by importing the whole build.xml file into a Gradle script and gradually translated it task by task (please refer to Gradle userguide to learn more about Ant/Gradle cooperation).

  2. Unknown User (darshakthakore)

    I strongly support moving from ant to some other tool that supports transitive dependency management. maven is the most common choice but as mentioned above, there are other "kids" on the block and it might be worth exploring them.

    Regardless of the tool chosen, i believe moving to a tool that provides dependency management is very much needed.

    I recently went thru the exercise of building openam from source and for the first time it was full day job simply because of the dependencies i had to download individually and making sure i download the right version. The README.TXT file in the source helps but is still missing certain info.

  3. Unknown User (barramundi)

    Authorization policies now is applied globally to any web agents connected. Any mis-configuration affects all agents no matter they are related or not.

    1) add agent association to policies - It would be good to have policies associated with agents or agent groups. So the policies can be isolated. It is also good for having different agents with different policies when they actually share same URL.

    2) Allow overlapping URL in various policies - the longest match wins. Currently URL rules cannot be overlapped. You cannot define a higher authorization policy for deeper level in the URI after you define the basic authorization for the root URI.

    Authorization service stability is still not industry standard at the moment. Mis-configuration cause un-authorized access or hung requests.

  4. Unknown User (

    Nice to have this page...but it feels like it needs some updating...

    Add please add improved debugging on the configurator.jar to aid headless deployments to the Install/Configure section.  This might be especially relevant as V12 becomes multi-tenanted.