AegisUSA is entering its 6^th year of business and recently implemented its 50^th instance of Sun Identity Manager. Over those 50 implementations of the Sun Identity Manager product, Aegis continues to develop unique products that allow for low cost, rapid deployments capable of solving many common identity problems inadequately addressed by out of the box software. This is no different with AegisUSA’s latest product “AegisUSA Privileged Access Management”, which greatly enhances the Sun IDM software.

One key issue that is often overlooked in complex identity implementations is Privileged Access Management.  You have an expensive and robust new identity system that handles everything you could have possibly thought of except one thing…. auditing and security for the users who implemented the system in the first place. Users like database/directory admins and IDM admins who essentially have “the keys to the kingdom” can login using these accounts leaving no trace of the physical identity behind the virtual super user. Essentially, the most powerful accounts with the greatest potential for damage are in no way controlled or audited by your IdM implementation. Wouldn’t it be helpful to have the capability to audit who has access to these accounts and furthermore, limit access to these accounts using the Identity Management System that was set up to prevent auditing nightmares like this in the first place?

There are many products out there today, which do some pretty amazing things when it comes to Privileged Access Management. What we have noticed, however, is that after spending large sums of money on an Identity Management System, organizations are somewhere between hesitant, frustrated, and downright angry having to dig back into their pockets to handle the security issues they thought they were addressing with the first purchase.

This is where AegisUSA’s Privileged Access Management Product fits into our client’s environment. Rather than addressing privileged access management as separate problem and solution, AegisUSA has used its expertise and real-world implementation requirements to develop a PAM solution as an add-on for Sun Identity Manager. This approach allows customers to add critical identity functionality to their environment while using their existing skill sets and software licenses.  Some of the key features of the AegisUSA PAM product include:

• Identity-based access to privileged accounts allowing for all actions to be traced back to a physical identity
• Role based access control providing limited accessibility to the privileged request process
• Customizable approval before access is granted
• Auditing of all access beginning and end dates as well as request history

All requests for access and approvals are made through the familiar Sun IdM interface. After receiving approval for access, the privileged accounts password is changed and the password is made available to the requestor. No one else is able to log in with this account until the requestor’s access time expires or the requestor relinquishes control. The PAM solution is designed to be configured and in production in less than 5 days.

The PAM product represents another tool in AegisUSA’s toolbox to help provide affordable and quality Identity Management solutions without the long timelines and extraordinary costs that are generally associated with Identity projects.  More details available on the product page: http://www.aegisusa.com/identity_management_solutions/pam/index.php

Please contact info@aegisusa.net for more information.

Normally a Shibboleth installation consists of an Apache web server acting as a proxy for the J2EE web application running on Tomcat. This is the officially supported methodology released by Internet2, however some users may desire the robustness of the Glassfish application server. I will attempt to explain here the process by which you can successfully deploy the application on Sun’s app server. First let me make this disclaimer, Glassfish is still incompatible with Shibboleth in some regards and may exhibit unpredictable behavior.

Now down to business, there are two main conflicts with the traditional way of deploying Shibboleth on Tomcat. The first is the REMOTE_USER login method which depends on an Apache login module and the proprietary ajp protocol interfacing Apache and Tomcat. Long story short, this is just not a feasible option to implement with Glassfish so I will ignore this method. An alternative is the JAAS username/password supported in the Shibboleth 2 IDP. This method uses Java classes running directly in the web application server, in this case Glassfish. When a user attempts to authenticate against the identity provider they will be presented a customizable login page that authenticates against a backend directory.

This brings us to the second problem, the default Shibboleth JAAS configuration happens to be incompatible with the one Glassfish uses for login to its administrative console. Two things must change in order to make these two play nicely:

1. The Xerces and Xalan xml parsers from Tomcat must be installed, trusted and configured
   1. The shibboleth installation includes JARs for both, locate and copy them into the glassfish install directory under /libs/endorsed
   2. Add the following JVM option from the glassfish web console for the domain you are working with:

-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

1. Add the following to your login.config under the shibboleth install directory/conf. This will allow you to continue to login to the glassfish console

fileRealm {

com.sun.enterprise.security.auth.login.FileLoginModule required;

};

ldapRealm {

com.sun.enterprise.security.auth.login.LDAPLoginModule required;

};

solarisRealm {

com.sun.enterprise.security.auth.login.SolarisLoginModule required;

};

jdbcRealm {

com.sun.enterprise.security.auth.login.JDBCLoginModule required;

};

1. Restart the domain

Assuming that you have correctly configured username/password authentication for shibboleth in the login.config file you should now be able to successfully deploy the shibboleth war in your glassfish domain and authenticate users against your directory.