All GroupWise authentication is handled by the POA - the Post Office Agent. Cache or remote mode seems to be an exception but it is not, because the GW client first authenticates you to the local database. It’s not a true authentication as authentication is usually an act against a service – it rather checks if the credentials provided match the database owner; but then it must authenticate you again to the POA in order to synchronise the local and the server database. The POA offers validation either against the internal database or by LDAP. The latter provides more options such as password quality and expiration which are correctly interpreted by the POA. This was the full story until December 8th 2015!
Since the release of GroupWise 2014 R2, the POA and Windows Client can also authenticate the user by the use of X.509 compliant User Attribute certificates, and by also implementing KeyShield SSO. At first glance this implementation looks like nothing at all. The only visible part is the KeyShield SSO Certificate field in the System Preferences form (figure 1). Here you can upload a trusted CA certificate or view details of an already uploaded certificate. However the underlying solution is professional and complex enough to merit a dedicated article.
What we need
The mechanism of certificate based authentication seems to be a piece of cake nowadays. Asymmetric cryptography allows you to sign the information (identity of the user) by something known only to the client (the private key) and then validate the signature by something known to everybody (the public key). Successful decoding by the public key proves encoding by the private key. The signing client is then verified by a certificate issued by a trusted Certification Authority. This certificate connects the client’s public key and the client’s identity. Yes, the process itself is a standard today. So, what is tricky?
Firstly GroupWise is a distributed system where the POA agents are responsible for authentication regardless of whether the user uses the Windows or WebAccess client. Each POA agent must be able to authenticate users of its own PO without any communication with other parts of the GroupWise system. Thus the trusted CA certificate uploaded first to any of the domains of the GroupWise system must be distributed to the whole distributed GroupWise system in such a way, that it remains “trusted”.
Please note: a common solution provided by many vendors is “manual” - wherever you want to validate a certificate, you have to upload, store or add its CA to an existing keystore. This approach can create a mess. Read on to learn about the solution designed by the Sorcerers from Provo.
Secondly the GroupWise client for Windows supports 3 basic modes - online, cache and remote. While online is just online with authentication against the POA, cache and remote modes both use the local database. This database is owned by a single user and protected by username and password. Cache mode in particular is very important and widely used because it lowers the network traffic; gives users the ability to work with or without a connection to the POA and works as fast as the local disk (send/receive is asynchronous in background). If users use certificates to authenticate to the POA, they should be able to use the same certificate to open their local database too.
The user’s identity validation process is the same and quite easy to implement as in the case of the POA. But what about the trusted CA certificate? The user must be able to open the database even without any contact with the POA. That means the trusted CA certificate must be local (figure 2). But compare the ratio: the manual distribution of CA certificates to POAs can create a mess even if you may have just a few or more POAs within the whole system. What about thousands, tens of thousands or even hundreds of thousands of users and their Windows desktops? This can create a total mess and many security problems.
OK, the GroupWise system should reach a higher or at least same level of security with certificate based authentication as in comparison with the traditional user/password. So how is this achieved?
Certificate authentication to the POA
When the POA receives the user’s certificate, it goes through these steps:
- Certificate validation: the certificate must be signed by the trusted CA certificate and the validation must be done during the certificate’s validity period. In order to validate the validity period successfully, time must be synchronised across all the POA servers and the certificate issuing server (the KeyShield SSO server) properly.
To avoid time synchronisation problems, KeyShield SSO allows you to define the not before skew parameter - then the certificate issued is valid in the past from the issuing server point of view - as explained in figure 3.
Please note - this validation is very strict. The CA certificate must be of the type used for digital signatures by individuals. Some customers have used a regular web site certificate and they were not able to authenticate using that certificate at all (with the GroupWise POA logging the failure as shown in figure 4). The certificate needs to have the Extended key Usage Attributes assigned to the user as illustrated in figure 5. The solution is to use self-signed certificates generated by KeyShield SSO. It’s not a risk because you generate the certificate at KeyShield SSO and import it manually at GW. It’s like a pre-shared secret.
- User matching. Once the certificate is validated, GroupWise tries to match the identity provided with an existing user account. Please refer to figure 5 which shows a X.509 user attribute certificate containing the GroupWise user’s email address (RFC822 Name) and LDAP GUID (ASN.1 ID 1.3.6.1.1.16.1 = UUID - in accordance with RFC 4530). Certificate authentication is available for LDAP synchronised users only, as manually created user accounts don’t have an LDAP GUID.
- Once the POA knows the identity of the user (i.e. information from validated certificate matches an existing user account), it creates a standard authenticated session as in the case of username/password authentication.
A CRL (Certificate Revocation List) is not used to check if the user attribute certificate has been revoked. It’s simply because these certificates are valid for a very short period of time, by default for a minute. So a CRL doesn’t make any sense.
Trusted CA certificate distribution and management
As discussed before, the trusted CA certificate must be locally available at each POA and each GroupWise client for Windows. GroupWise has its own secured trusted certificate distribution process which is implemented as a part of System Address Book synchronisation. This works between domains, down to POs and then to clients (in cache mode). Once an admin uploads the trusted certificate, it is distributed like information about a new user account.
Please note that if you already have a trusted CA certificate uploaded and you decide to use another one, its not distributed down to clients immediately. You should check your “Create Deltas” and “Generate Address Book For Caching” plus the setting on the client side. Of course, if you do nothing, the certificate will still be distributed by the GroupWise mechanism.
Single Sign On GroupWise client for Windows
The GroupWise client for Windows obtains the user’s certificate automatically. It works with the KeyShield SSO client for Windows API. When you start the GroupWise client, it checks if the KeyShield SSO client API is present. Then GroupWise asks if the user is authenticated and if so, GroupWise finally requests the user’s identity certificate.
The certificate generated by the built-in KeyShield SSO CA is shown in figure 5. The certificate is then used for authentication against the POA in the case of online mode or validated locally in order to open the user’s local database in the case of cache mode.
Single Sign On for WebAccess
Whenever a user knocks on the WebAccess door, WebAccess can ask KeyShield SSO who is behind the source IP address. IP address sounds like a crazy idea but don’t miss the fact that each device has to run the KeyShield SSO client. This provides very strong protection against possible attacks. WebAccess is available for Windows, MacOSX, Linux, iOS and Android.
Once WebAccess obtains the certificate, the authentication process is the same as in the case of the GroupWise client for Windows online mode. The WebAccess client needs to know about the KeyShield SSO server so all the necessary information must be entered into webacc.cfg configuration file.
Please note that the certificate you should provide here is NOT the CA certificate. It is the SSL certificate of the https interface of KeyShield SSO which allows WebAccess to validate KeyShield SSO server’s identity. The server security relies on the CA issued certificates; it’s smart to use the server’s identity validation if they are not sited next to each other in one server room or VMWare cluster.
Conclusion
Certificate based authentication was primarily implemented to extend SSO capabilities – the GroupWise client for Windows offers SSO in both online and cached modes; WebAccess allows SSO from virtually any device (Windows mobile can be supported too, just nobody has asked for it so far).
With the excellent certificate distribution mechanism deployment is unbelievably easy. Once you upload the trusted CA certificate, you users can profit out of SSO very quickly. Further information on Keyshield SSO is available at www.keyshieldsso.com.
Future
As KeyShield SSO now provides a complete set of functions - SSO, SLO and RELOGIN - GroupWise integration can also be extended to all customers who utilise shared computers, e.g. - in HealthCare and Education. You can support the idea here: https://ideas.microfocus.com/MFI/novell-gw/Idea/Detail/1475.
This article was first published in OHM Issue 34, 2016/3, p20-23.