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.
.
"The no plug-ins configured for this operation" means that there was no Data Store configured in the realm to perform the operation. This could either mean that there was no data store configured in the realm at all, or could just mean that the list of supported types and operations setting didn't contain the corresponding entry as you found.
ReplyDeleteThe read, create, edit and delete operations are quite self-explanatory, but the "service" value means that service related operations can be performed on the user entries (normally only users have service attributes). The service attributes are essentially things that you can configure under Subjects -> User -> Services tab, e.g. user-specific session timeout settings, or login success/failure URLs, etc.
The realm=service is a very internal thing for OpenAM and is used by buggy things like OPENAM-1323.
Hopefully this helps in the future. ;)
Thanks! I always wonder what is "service" supposed to function in OpenAM.
ReplyDelete