This tutorial will explain how to configure GroupWise WebAccess as an AppMark for NetIQ CloudAccess/MobileAccess.  This feature is particularly useful for BYOD situations, such as when an employee wishes to access GroupWise, but does not wish to have corporate restrictions or store their corporate password on their personal device.  This tutorial has three main components:

• Configuring Password Fetch in NetIQ Access Manager

• SSO Between NetIQ Access Manager and GroupWise WebAccess

• Federating NetIQ Access Manager and NetIQ CloudAccess

Prerequisites

• Installation of Novell GroupWise WebAccess, NetIQ Access Manager, NetIQ eDirectory, and NetIQ CloudAccess 2.0

• Universal Password enabled in eDirectory for the Access Manager LDAP connection

• GroupWise WebAccess configuration (details on http://www.novell.com/support/kb/doc.php?id=7010088)
  
  
  
  • On the WebAccess server, open the webacc.cfg file in a text editor and edit the following lines
  
  
• Cookie.domain=.yourcompany.com (should be the common part of the domain between the NAM and WebAccess)

• Security.Authenticate.header=xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx (comma separated list of the Access Gateway IP addresses)

• Security.Logout.Url=namwebaccess.yourcompany.com/AGLogout (optional)

Configuring Password Fetch in Access Manager

Currently, GroupWise WebAccess requires the user's real password to be sent in the authentication header from Access Manager.  Since the authentication between CloudAccess and Access Manager is handled with a SAML assertion, Access Manager does not have the user's real authentication information to use in the identity injection.  To get around this, we need to enable password fetch in Access Manager and configure it as a post authentication method in the SAML configuration (more on the post authentication method later).

First, we need to be sure that Universal Password is enabled in eDirectory for the administrative account that Access Manager uses.  When this is done, create a new authentication class in the IDP settings, using the PasswordFetchClass.  In most situations, you will want to use the Universal Password option and to look up the password based on the user's CN.  These options are outlined in the first two images below.  You will then need to create an authentication method based on this class and the user store from which you need to retrieve the password.

SSO Between NetIQ Access Manager and GroupWise WebAccess

The next part of this tutorial is to enable SSO between Access Manager and GroupWise.  By itself, this is a nice feature to have enabled because it adds a layer of protection for the WebAccess server, and it is convenient for desktop users.

Enabling SSO between Access Manager and WebAccess is pretty straightforward.  First, create a path or domain based accelerator and point it to your WebAccess server.  Make sure to use port 443 and enable SSL on the web server configuration tab.  Next, create a protected resource, either as /* or as /gw/webacc/* and require a contract.  After this is done, configure an identity injection for Access Manager to inject the username and password into an authorization header and enable this for the protected resource (see related screen shot).

Once you have applied these settings, you should be able to access the accelerator address, log into your IDP, and see your mailbox in WebAccess.  Now, let's get it working with MobileAccess.

Federating NetIQ Access Manager and NetIQ CloudAccess

This part of the tutorial will have you configure CloudAccess as a SAML2 IDP for Access Manager.  This will allow one touch access to everything protected by Access Manager, including WebAccess.  This may be challenging if you have not configured Access Manager as an SP before, but the screen shots should help guide you in this configuration.

• First, log into CloudAccess and configure a new NAM connector
  
  
  
  • Use the metadata from your IDP (https://youridp/nidp/saml2/metadata) to configure the connector
  
  
• The signing certificate can be downloaded from your SP trusted root configuration or obtained directly from the metadata

• The connector configuration screen also provides more detailed federation instructions

• At this point, you will need to choose the attribute that you want to map in the federation.  CloudAccess and Access Manager can use different user stores, as long as you can find an attribute that is consistent between them.  I used the employee ID, which was mapped to "X-Custom1" in the CloudAccess user store configuration.

• You may configure the WebAccess AppMark at this point, but it is easier to test by pointing the default AppMark at a more basic basic protected resource

• Apply the NCA configuration

• In Access Manager, you will first want to create your attribute set and matching expression
  
  
  
  • You will see both options under your IDP "Share Settings" tab
  
  
• Create a new attribute set, with a mapping between the remote attribute "NameID" and the corresponding attribute in your user store

• Create a matching expression based on the attribute configured above

• Under the SAML 2.0 tab in the IDP cluster configuration, add a new identity provider
  
  
  
  • Import the metadata from https://yourcloudaccess/osp/a/t1/auth/saml2/metadata (also found in the NAM connector instructions)
  
  
• Under "Attributes", add the attribute you defined earlier in the new attribute set

• Under "User Identification", select the attribute matching and configure the attribute matching settings with the matching expression you created earlier

• Under "User Identification, also set the Password Fetch method that you created earlier as a post-authentication method

• Configure the authentication card to fulfill the authentication contracts that you wish to use for federation.  If you haven't done so already, make sure to modify these contracts to be satisfiable by an external provider.

• Choose "unspecified" for the name identifier format

• Import the CloudAccess signing certificate and certificate chain into your IDP trusted root store

• Apply the configuration in Access Manager

At this point, you should be able to test the federation by logging into CloudAccess from your desktop and selecting the NAM AppMark that you configured.  If you were able to access the protected resource, congratulations!  If not, here are some common pitfalls to look for:

• Missing or incorrect certificate in IDP trust store

• Contract not satisfiable by external provider

• Incorrect attribute mapping

Troubleshooting is outside the scope of this tutorial, but the SAML tracer Firefox extension and the IDP logs can be quite valuable tools for identifying other issues.

Once you have made it this far, the last step is configuring the WebAccess AppMark.  Configure a new AppMark under the NAM connector and set the mobile device URL to https://youraccelerator/gw/webacc.

The default WebAccess configuration does not recognize all mobile and tablet devices, so you have two options for providing the proper interface to all devices.  The first is to configure the list to accept a wider range of User-Agent strings, although that may involve ongoing maintenance as new devices are created.  The more foolproof way is to append "?User.interface=mobile" to the mobile device URL, which will override the User-Agent setting in WebAccess.

Good luck!

[gallery link="file" columns="2" ids="56918,56917,56922,56921,56928,56933,56923,56920,56919,56927,56926,56925,56924"]