Google Authenticator Integration Kit

PingIdentity just added Google Authenticator Integration Kit to its PingFederate product line.

From a technical standpoint, what exactly does this kit do? First, strictly speaking, the name is a bit misleading. A more technically accurate name would be the "RFC 6238 Compliant Time-Based One-Time Password Integration Kit", but that's kind of a mouthful.  

A One-Time Password (OTP) is used to augment password authentication (something you know) by prompting the user for a code generated by a token or other device that only the user possesses (something you have).  

The code can only be used once, and even then it's useless outside of a specific time window. OTP-based authentication is nothing new for Ping. We've enabled integration with commercial OTP and other strong authentication solutions for years.

But now the Google Authenticator kit allows for the use of a mobile phone app to generate the requested code, making OTP authentication an option where traditional hardware tokens are too expensive or logistically challenging.

By the way, Google Authenticator integration has been available on ForgeRock OpenAM since 2 versions back. I have a blog on it - OpenAM with HOTP and OATH.

.

OpenAM 10.0.2 released!

OpenAM 10.0.2 is a relatively silent release. It was made available on 20th Dec 2013 to customers with ForgeRock Subscriptions.

 

There is a long list of fixes for this release. You can read it from here in the release note.

Besides fixes, there are some enhancement made. I highlighted some below:

The changes for OPENAM-3330 and OPENAM-3353 affect the service configuration LDAP and Active Directory authentication modules. 

OPENAM-2765: DirectoryManagerImpl, IdRepoJAXRPCObjectImpl and SMSJAXRPCObjectImpl should return cluster unique IDs when registering notification URLs  

OPENAM-2604: Password reset should have configurable mail attribute  

OPENAM-2354: Zero Page Login should be configurable

Download and try it!

.

Application user ID is not valid. errorCode=107

Sometimes, debugging issues with Policy Agent can be a pain (somewhere :>). So, I spent 2 days helping a customer remotely with his Policy Agent issue.

He just installed a IIS 7 Policy Agent and upon IIS starts, he always get the following error in agent debug log:

2013-12-17 14:36:47.919    Error 3076:2252 AuthService: AuthService::processLoginStatus() Exception message=[Application user ID is not valid.] errorCode='107' templateName=login_failed_template.jsp. 

2013-12-17 14:36:47.919    Error 3076:2252 all: ProcessRequest(): Agent intialization failed.

Isn't this error clear? -- "Application user ID is not valid".

My initial response was straight-forward - "You have not create an agent of the same profile name in OpenAM Administration Console. Go do it and you'll be able to resolve."

In the end, I found out that the agent was already created. The password was also correct (I was able to manually log-in to OpenAM console using the agent name and password).

A telnet from the IIS server to the OpenAM server was also successful!

Hmmm… very strange… However, when I tail the agent debug log and the Authentication debug log on the OpenAM server, something was missing.

The Authentication debug log never moved, even when I set the debug level to Message.

How can it be?

I then set all:5 on the Policy Agent side and debugged further. This was real verbose, mind you. I need to spend time tracing carefully.

We know that there are XML content passing around whenever the Policy Agent talks to a OpenAM server. Initially, I still could not find anything wrong with the configuration, until a few more rounds of restarting/testing later.

Bingo!

How come the XML content has the FQDN of the development OpenAM server? We are trying to connect to UAT OpenAM server, no?

Finally, I found out that the customer has mistakingly keyed in the IP address of the development OpenAM server into the /etc/hosts of the IIS server.


Network 101 - A telnet to the FQDN of the OpenAM server is not good enough. Is the IP address of the OpenAM server correctly pointing to the appropriate server?


.

OpenAM Web Policy Agents 3.3.0

Have you tried the latest OpenAM Web Policy Agents 3.3.0?

It would be good to do some homework before installing/upgrading. I find this a good start point.


Some highlights below:

Important Changes to Web Policy Agent Functionality

• IIS web policy agents no longer rely on the Windows registry to determine where to find configuration settings. 
• The default policy evaluation mode for new policy agent profiles is now self rather than subtree, in order to better scale for large numbers of policy rules.

Deprecated Functionality

• Support for Microsoft IIS 6 is deprecated, and likely to be removed in a future release.

Removed Functionality

• Web policy agent support for Apache HTTP Server 2.0 is no longer provided in this release.
• Web policy agent support for Oracle iPlanet Web Proxy Server (formerly Sun Java System Web Sun Proxy Server) is no longer provided in this release.

The default policy evaluation mode set to self is a good move. This allows the agent to scale better. No one will miss Apache HTTP Server 2.0 and Oracle iPlanet Web Proxy Server. However, there'll still be some customers still using Microsoft IIS 6. 

Top new features I personally welcome:

• All of the web policy agents have been updated to include support for Internet Protocol version 6 (IPv6) support, in addition to support for IPv4.
• This release adds a new web policy agent for Varnish Cache.
• Web policy agents now support IPv6 for notenforced IP addresses.
• A web policy agent is now available for Apache HTTPD Server 2.4.
• Web policy agents can now conditionally redirect users based on the incoming request URL
• The IIS 7 web policy agents now has support for HTTP Basic authentication and password replay, thereby better supporting Microsoft OWA and SharePoint

IPv6 seems common these days. Agent-support for IPv6 is very welcomed. 

I was at a customer site more than 6 months ago. This customer has OpenSSO deployed and I was asked about IPv6 support in OpenAM. I sent an email to ForgeRock and was informed IPv6 will be supported fairly soon. It has arrived!

I was told by the same customer that another product vendor had indicated IPv6 on their roadmap. Well, it's still on the roadmap as of today. Nothing has updated since. Sales pitch. Yes, typical salesman.

It is also fairly common for SharePoint integration these days. Almost every customer of ours own a Microsoft Active Directory and they usually require integration with their SharePoint server. (Side track a bit: Do not ever forget AD in code development and QA. :> These are real paying customers! ) 

Lastly, some limitations to take note of:

Limitations

• Web policy agents for IIS do not support Web gardens nor multi-process mode. 

• If you are running an Apache Web agent on RHEL 6 (CentOS 6), and are also running SELinux in enforcing mode, Apache may fail to restart with a 'Permission denied' message, with a pointer to a file in the/path/to/web_agents/apache2x_agent/lib directory. SELinux expects most library files to be configured with alib_t label; you can set that up with the chcon -t lib_t /path/to/web_agents/apache2x_agent/lib/*.so andsemanage fcontext -a -t lib_t /path/to/web_agents/apache2x_agent/lib/*.so commands.

I'll be trying the new agent as soon as I wrap up testing OpenAM 11.0.

.

OpenAM 11.0.0 Upgrade - Persistent Search Error

In OpenAM 11, the Identity Repositories (IdRepo) has been revamped. The new implementation is using OpenDJ LDAP SDK to perform LDAP operations. 

(If you want to know more about IdRepo, read from Peter's blog - Identity Repositories. He knows IdRepo inside out. :> )

I observed two errors when I configured an external OpenDJ and Microsoft Active Directory as additional Data Store.

If you are connecting to an external OpenDJ server (e.g. OpenDJ 2.6.0), the following error is frequently displayed in IdRepo:

PersistentSearch:12/11/2013 03:52:06:353 PM SGT: Thread[OpenDJ LDAP SDK Default Scheduler,5,main]ERROR: An error occurred while executing persistent searchorg.forgerock.opendj.ldap.ConnectionException: Server Connection Closed: Heartbeat timed out after 500 ms        at org.forgerock.opendj.ldap.ErrorResultException.newErrorResult(ErrorResultException.java:163)        at org.forgerock.opendj.ldap.ErrorResultException.newErrorResult(ErrorResultException.java:125)        at org.forgerock.opendj.ldap.ErrorResultException.newErrorResult(ErrorResultException.java:76)        at org.forgerock.opendj.ldap.HeartBeatConnectionFactory.newHeartBeatTimeoutError(HeartBeatConnectionFactory.java:1326)        at org.forgerock.opendj.ldap.HeartBeatConnectionFactory.access$000(HeartBeatConnectionFactory.java:107)        at org.forgerock.opendj.ldap.HeartBeatConnectionFactory$ConnectionImpl.checkForHeartBeat(HeartBeatConnectionFactory.java:816)        at org.forgerock.opendj.ldap.HeartBeatConnectionFactory$ConnectionImpl.access$2300(HeartBeatConnectionFactory.java:238)        at org.forgerock.opendj.ldap.HeartBeatConnectionFactory$1.run(HeartBeatConnectionFactory.java:1103)        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)        at java.util.concurrent.FutureTask.run(FutureTask.java:138)        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)        at java.lang.Thread.run(Thread.java:662)

Of course, restarting process immediately kicks-in:

PersistentSearch:12/11/2013 03:52:06:354 PM SGT: Thread[OpenDJ LDAP SDK Default Scheduler,5,main]Restarting persistent search connection against: LoadBalancer(Failover(AuthenticatedConnectionFactory(HeartBeatConnectionFactory(LDAPConnectionFactory(xxx.yyy.sg/192.168.x.x:1389)), SimpleBindRequest(name=cn=Directory Manager, authentication=simple, controls=[]))))PersistentSearch:12/11/2013 03:52:07:378 PM SGT: Thread[SystemTimerPool,5,main]Starting persistent search against baseDN: dc=azlabs,dc=sg, scope: sub, filter: (objectclass=*), attrs: [dn] against LoadBalancer(Failover(AuthenticatedConnectionFactory(HeartBeatConnectionFactory(LDAPConnectionFactory(xxx.yyy.sg/192.168.x.x:1389)), SimpleBindRequest(name=cn=Directory Manager, authentication=simple, controls=[]))))

If you are connecting to an external Microsoft Active Directory server, the following error is frequently displayed in IdRepo:

PersistentSearch:12/11/2013 04:06:04:265 PM SGT: Thread[OpenDJ LDAP SDK Connection Timeout Checker,5,main]ERROR: An error occurred while executing persistent searchorg.forgerock.opendj.ldap.TimeoutResultException: Client-Side Timeout        at org.forgerock.opendj.ldap.ErrorResultException.newErrorResult(ErrorResultException.java:182)        at com.forgerock.opendj.ldap.AbstractLDAPFutureResultImpl.setResultOrError(AbstractLDAPFutureResultImpl.java:125)        at com.forgerock.opendj.ldap.AbstractLDAPFutureResultImpl.adaptErrorResult(AbstractLDAPFutureResultImpl.java:114)        at com.forgerock.opendj.ldap.LDAPConnection.cancelExpiredRequests(LDAPConnection.java:562)        at com.forgerock.opendj.ldap.TimeoutChecker$2.run(TimeoutChecker.java:92)

Again, restarting process immediately kicks-in:

PersistentSearch:12/11/2013 04:06:37:347 PM SGT: Thread[OpenDJ LDAP SDK Connection Timeout Checker,5,main]Restarting persistent search connection against: LoadBalancer(Failover(AuthenticatedConnectionFactory(HeartBeatConnectionFactory(LDAPConnectionFactory(ad1.XXXX.sg/192.168.xx.yyy:389)), SimpleBindRequest(name=CN=SSO Service Account,CN=Users,DC=XXXX,DC=sg, authentication=simple, controls=[]))))PersistentSearch:12/11/2013 04:06:38:373 PM SGT: Thread[SystemTimerPool,5,main]Starting persistent search against baseDN: DC=XXXX,DC=sg, scope: sub, filter: (objectclass=*), attrs: [dn, isDeleted, whenChanged, whenCreated] against LoadBalancer(Failover(AuthenticatedConnectionFactory(HeartBeatConnectionFactory(LDAPConnectionFactory(ad1.XXXX.sg/192.168.xx.yyy:389)), SimpleBindRequest(name=CN=SSO Service Account,CN=Users,DC=XXXX,DC=sg, authentication=simple, controls=[]))))

Why? I do not know. I hope improvement can be made to this.

.

Deprecated Password Storage Scheme

I know all along there is a default Password Storage Scheme in OpenDJ. However, I did not know there is a Deprecated Password Storage Scheme until I found out from Ludovic just now.

We were in a discussion on how to migrate users from OID to OpenDJ. I know the default userPassword hashing algorithm for Oracle Internet Directory has been changed from MD4 to SHA, while OpenDJ is using SSHA as the default password storage scheme.

I need a seamless way to migrate users over without having each user to change his/her existing password.

When you change the password storage scheme for users, realize that the user passwords must change in order for OpenDJ to encode them with the chosen storage scheme. If you are changing the storage scheme because the old scheme was too weak, then you no doubt want users to change their passwords anyway.  

If however the storage scheme change is not related to vulnerability, you can use the deprecated-password-storage-scheme property of the password policy to have OpenDJ store the password in the new format after successful authentication. This makes it possible to do password migration for active users without forcing users to change their passwords.

Bingo! Nice!

.

Mobile Device Management - Part III

I just finished reading Instant XenMobile MDM - a very simple book with only 46 pages.

The book compares container-based solutions by many other vendors with the application-based enforcement found in Citrix XenMobile MDM (mobile device management). Container-based solutions are applications that embed corporate data, e-mail, contact, and calendar data.

Unfortunately, in many cases these solutions break the user experience by limiting how they can use native applications. XenMobile does this without compromising the user experience, allowing the secure applications to exist and share the same calendar, contact, and other key integration points on the mobile device. They were the only vendors at the time of writing this book, that had a single management platform which provided MDM features with secure storage, integrated VDI, multitenant, and application load balancing features, which we believe are some of the differentiators between XenMobile and its competitors.

The concept of Citrix XenMobile MDM is very similar to that of Blackberry Enterprise Server, except it supports more devices. It has integration with Apple iOS 7 MDM APIs as well as Samsung KNOX and Amazon MDM platforms extend the 60+ application-specific policy controls of XenMobile.

A "Quick start - setting up your XenMobile Server" follows in subsequent chapter. The setting up of Citrix XenMobile MDM is fairly straight-forward. (This reminds me of BES server installation sometimes back. Very simple and fast to deploy)

It covers specific platforms like Apple iOS and Samsung SAFE (Samsung for Enterprise).


The book ends with "Top 6 features you need to know about".

1. Reporting
2. Application stores
3. Secure Mobile Gateway
4. The XenMobile service manager
5. Dashboard management
6. Common management tasks

There are many reports which are mostly self-explanatory. E.g. OS version, OS type, Device Type. The more interesting report will be those that list the jailbroken devices and rooted devices.

I am more interested in Secure Mobile Gateway since I'm a Mail person (used to deploy numerous Sun Messaging Servers in the South-East Asia region), besides IAMS.

Secure Mobile Gateway provides granular access control for e-mail and calendar applications on devices that support Microsoft ActiveSync. ….

The benefit of Secure Mobile Gateway is that it ensures that a user won't bypass your XenMobile policies that are being enforced on devices. A user who does not agree with your policies may decide to skip enrollment. He may have somehow decided that he does not need corporate applications that are being pushed or other device centric policies. However, typically most users will need access to their e-mail from their devices. If a user somehow figures out the necessary settings and credentials to configure his device manually, Secure Mobile Gateway can intercept that connection and make policies decisions based on an organization's needs. In other words, you could stop a user from accessing e-mails until he enrolls in the XenMobile MDM solution..

Citrix Secure Mobile Gateway works as an ISAPI plugin on the same server with Microsoft Forefront Threat Management Gateway.

Hmm… I thought Microsoft has announced discontinued support for Microsoft Forefront Threat Management Gateway? No, it still has mainstream support until April 2015 and extended support until April 2020. Good to know.



.

Mobile Device Management - Part II

In October, I blogged about Mobile Device Management and I was thinking aloud about how a traditional IDM product can add-on a new feature to provision to a MDM product.

  

The next feature will definitely be able to bridge the gap between identities from enterprise customers (most likely, in-house Microsoft Active Directory) and MDM products. I do not think we should cross the path of building a MDM product from scratch. That would be too far-fetching. 

This would be a one-stop solution.

This morning, an email came from SailPoint announcing the release of IdentityIQ 6.2. 

Dream comes true! Yes, indeed.

Highlights of what’s included in the new release:

• First of its kind integration with mobile device management (MDM) solutions from AirWatch, Good and MobileIron
• Re-styled user interface with crisp, clean look-and-feel
• Expanded scalability support for critical IAM processes
• Enhanced administrative user experience with improvements to workflow and quick link configuration
• Separation-of-duty (SoD) policy simulation
• End user tablet support (iPad)
• Integration support for STEALTHbits, Cyber-Ark and Microsoft FIM
• Expanded healthcare integration with Epic & GE Centricity connectors

These days, any IAMS product will want to get "friendly" with mobile devices. Why not? It's a super huge market in the mobile space.

.

Yammer!

Yammer looks cool! Just signed up a free account to play around with my co-workers.

Hopefully, it can seamlessly integrate with our on-premise SharePoint server. Most importantly, do not give me problem with mobile access! :)

.

Where to store Password Policy?

Any Single Sign-On product in the market will need to talk to a back-end User Store for authentication purpose. A User Store can be a traditional LDAP server or a modern Microsoft Active Directory Server.

Now, the SSO product fronts the end-users and this is where Password Policy is enforced. (Of course, if a corporate environment is using Microsoft platform, then password policy can be enforced during the Windows logon process)

Today, I talked to a Product Pre-Sales engineer and was pretty pissed off. She knew my team is managing the SSO product, as well as the LDAP server for a customer. We have a migration exercise going on at the moment.

My customer wants us to make use of the out-of-the-box features from the SSO product as much as possible - to the extend of making sure the Password Policy implemented on the LDAP server can be seamlessly integrated with this SSO product.

We spent a few days reading up and setting up a POC in our labs. We confirmed that this SSO product is not able to "interact" with any underlying LDAP server with regard to Password Policy management. It is only able to implement its own password policy.

She insisted that the RIGHT WAY of doing thing is for the SSO product to enforce password policy for the corporate.

This is "vendor-lock-in" strategy. You think customer is stupid?

I have implemented many SSO projects. In Sun's days, when the old Sun Access Manager and OpenSSO server could not integrate seamlessly with Microsoft Active Directory, we did not tell our customers that was the wrong way of enforcing password policy and they should use Sun AM/OpenSSO built-in password policy instead.

We stripped the codes and implemented custom authentication module for our customers.

User Store (LDAP server or Microsoft Active Directory Server) should be the authoritative password policy enforcer.

Wake up, lady!

.