Huge IoT Market

I was watching The Identity of Things & The Smart Cities of Tomorrow Webinar May 2015 (YouTube here).


There was a slide that caught my attention.

Huge numbers! IoT is getting more and more exciting!

And my team was joking that IPv6 has not been adopted widely enough, at least in our region. How are we going to see IoT happening?

.

New Sign-In from Chrome on Windows - Adaptive Risk Authentication

I was using a shared laptop just now and tried logging on to Gmail. As soon as I logged in, I received an email from Google warning me of "New Sign-In from Chrome on Windows".

This feature is good especially now that the Internet seems an "unsafe" place to be in. :>

Can the same feature be implemented in OpenAM? I believe it is possible by extending the codes in Adaptive Risk Authentication module.

Shouldn't be too difficult to achieve. Let me find some time. :)

.

Online export of OpenAM Configuration data from OpenDJ

We all know that the OpenAM configuration which we managed via the OpenAM Administration console is stored in either an embedded OpenDJ server (by default) or an external OpenDJ server.

For production systems, it would be recommended to backup the OpenAM configuration data nightly, specifically ou=services,o=[your organization]. 

I'm not too sure about ou=opensso adminusers,o=[your organization], but I'll backup a copy just to play safe.

Operationally, how huge will this OpenAM configuration data be? I can safely say it's very small. Will it have any performance hit on the OpenDJ server? Not likely. If the OpenDJ server is embedded which shares the same JVM as OpenAM, will it affect the functioning of OpenAM server? Not likely.

Anyway, we are talking about backup during off-peak hours, ain't we?

.

Porting embedded OpenDJ in OpenAM to external OpenDJ - Part IV

I blogged a few times on the procedures to port embedded OpenDJ in OpenAM to external OpenDJ. See Part I, Part II and Part III.

So we are happily done with the migration from embedded to external OpenDJ. What's next?

There is a last mile -- clean up!

Remember the old embedded OpenDJ is started whenever OpenAM is started? It stays in the same JVM as OpenAM (you'll get it if you are in the Java world).

So this is to say even if OpenAM is configured to point to external OpenDJ, the old embedded OpenDJ will always be started whenever OpenAM is started. Simple logic.

So, how can we stop the old embedded OpenDJ from starting?

.../[openam-configuration-directory]/opends is where the embedded OpenDJ stays. 

Remove or rename the folder will do the trick. (I usually rename, never remove in case I want to roll back)


Done.

.

Data Store, LDAP User Attributes and Subjects

In my previous blog Global Session vs User Session, I mentioned how to go about configuring Session settings on a per-user basis. 

First, go to the Subjects tab and search for the User.

Then, we set a different Session setting for the user. In this example, we change the Maximum Idle Time for this user from the default 30 minutes to 60 minutes.

Fairly simple from UI perspective, but what really happens behind the scene?

There is a need to map Maximum Idle Time from the UI to an attribute in the user's LDAP entry. In this case, OpenAM makes use of an attribute iplanet-am-session-max-idle-time.

So that means OpenAM needs to be able to edit the user's LDAP entry. (see the other blog of mine) More importantly, the backend Data Stores (e.g. LDAP) must have the necessary attributes defined in the schema. (e.g. iplanet-am-session-max-caching-time, iplanet-am-session-max-idle-time, iplanet-am-session-max-session-time, iplanet-am-session-quota-limit)

In Data Stores, click on the appropriate backend. 

Scroll to the section LDAP User Attributes. Ensure that the necessary attributes are defined. 

Embedded OpenDJ
If the backend is an embedded OpenDJ that is installed together with OpenAM, then we are fairly sure the OpenDJ schema is populated with the required session attributes. The schema is defined in ...//opends/config/schema/99-user.ldif .

External OpenDJ
If the backend is an external OpenDJ, we need to ensure the external OpenDJ is chosen during OpenAM installation. The installation will ensure the appropriate attributes are created in 99-user.ldif.

If the external OpenDJ is configured post OpenAM installation, then we need to ensure 99-user.ldif from the embedded OpenDJ is copied to the the external OpenDJ. One can choose to load the schema manually with pre-defined ldif files in ...//ldif/opendj/.



The above 2 scenarios are quite straight-forward. What if the backend is Microsoft Active Directory or any of the supported user data stores?

Remember we said earlier that we need to load the necessary attributes into the OpenDJ schema? The same has to be done on any other User Data Stores. 

Well, this becomes tricky. 

Will the AD administrator allow non-AD related attributes to be created on the AD? Likely not. This is not a technical issue, but an operational one.


.

Global Session vs User Session

We all know there is a Session tab in OpenAM Administration console listing all the current sessions in a particular OpenAM node. In the Session table, there are 2 columns "Max Session Time" and "Max Idle Time".

We all know that the Session for every user can be configured globally in Configuration ++ Global +++ Session.

Click on Session and scroll all the way down to Dynamic Attributes section. This is where Global Session is configured.

Is it possible to configure a different Maximum Session Time and/or Maximum Idle Time on a per-user basis in OpenAM? 

The answer is yes, but we seldom do that as this is really a operational headache. Some customers of ours will instead opt for different Session setting on a per-department basis. This will be via some customized codes in Post Authentication Processing module and determined by a certain attribute (e.g. departmentCode) in the users' LDAP (or Microsoft AD) entry. 

Suppose a customer insists on having different Session setting on a per-user basis, the following is how we go about achieving that. 

1) Go to Subjects tab and search for the user

2) We can see that the Session service is currently not available for this particular user. This implies the values are inherited from Global Session setting which we discussed earlier.

3) Click on Add

4) Choose Session and click Next.

5) This is where different Session values can be set on a per-user basis. Click on Finish.

6) We are done.

Nice!

.

com.sun.identity.idm.IdRepoException: No plug-ins configured for this operation

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.

Recently, we launched Facebook social login for this customer.

The following OAuth 2.0 Authentication Features is lifted from ForgeRock Wiki:

1. The module offers the possibility to authenticate a user and map the account in different ways:
   1. Without any local identity in the OpenAM, however identifying the user by one of the attributes provided by the OAuth 2.0 provider
   2. Map the user to an "anonymous" account in the OpenAM
   3. Map the user to a local identity based on the attributes received from the OAuth 2.0 Provider
   4. Create an account on the fly on the OpenAM local user data store with the attributes received from the OAuth 2.0 Provider
2. Global Logout as an option to also terminate the session with the OAuth 2.0 Provider
3. Provide the access token and attributes obtained to trusted applications that use the OpenAM
4. 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.

.