In Data Store ++ Plug-in Configuration +++ LDAPv3 Plug-in Supported Types and Operations, the default settings for realm, user and group are grant-all operations.
In Production, it is a good practice to restrict the operations that are allowed for OpenAM to execute on the backend data store. e.g. OpenDJ or Microsoft Active Directory.
The rationale is simple. We only want OpenAM to consume data from the backend data stores. OpenAM shall not be used as an Identity Management tool.
For most of our deployment, we will remove create and delete operations. For one of our customers, edit operation is intentionally not removed as we have custom codes in Post Authentication Processing module that will update some attributes in users' LDAP entries.
The following OAuth 2.0 Authentication Features is lifted from ForgeRock Wiki:
- The module offers the possibility to authenticate a user and map the account in different ways:
- Without any local identity in the OpenAM, however identifying the user by one of the attributes provided by the OAuth 2.0 provider
- Map the user to an "anonymous" account in the OpenAM
- Map the user to a local identity based on the attributes received from the OAuth 2.0 Provider
- Create an account on the fly on the OpenAM local user data store with the attributes received from the OAuth 2.0 Provider
- Global Logout as an option to also terminate the session with the OAuth 2.0 Provider
- Provide the access token and attributes obtained to trusted applications that use the OpenAM
- The Account Mapper, Attribute Mapper and Email gateway can be extended since they are implemented as plug-ins
So, during unit testing, we always hit into "com.sun.identity.idm.IdRepoException: No plug-ins configured for this operation" error during Step d.
We were initially lost, but eventually realised it was caused by the missing create operation in LDAPv3 Plug-in Supported Types and Operations.
Once the create operation is added, the Facebook account is now able to be created on the fly.