VSJ Standard Edition 3.2 (aka "VSJ 3.2") has been released and is now available for download, both via the VSJ evaluation download form at
http://www.vintela.com/vintela-single-sign-on-for-java-evaluation/
and from Quest Support.
What's new?
VSJ 3.2 adds support for LDAP queries to Active Directory (secured by Kerberos, of course). For the common case of retrieving LDAP attributes from the client's AD User object, VSJ 3.2 introduces a new API (the com.wedgetail.idm.simpldap.attributes.* package), illustrated by the new 'ldap' example, to simplify this case. For other LDAP scenarios VSJ 3.2 facilitates using the JNDI/LDAP/SASL code in JDK 1.4 (or above) with VSJ Kerberos credentials -- either delegated Kerberos credentials from the client or VSJ's own Kerberos credentials -- and the 'ldap2' example illustrates this.
VSJ 3.2 also adds support for mixed environments where some clients support SSO (SPNEGO or NTLM) but, for whatever reason, other clients cannot use SSO and instead must perform username/password login (normally HTML forms-based authentication). The new 'sso-and-forms' example illustrates this. This functionality addresses a scenario that a number of VSJ users have encountered in their environments, exemplified in this thread: http://vintela.inside.quest.com/thread.jspa?threadID=1924&tstart=0
VSJ 3.2 provides easier ways to configure VSJ and to test a VSJ configuration before VSJ-enabled web apps are deployed to a Java app server. In previous releases, VSJ only looked for its configuration parameters in the deployment descriptor (WEB-INF/web.xml). In this release that approach is still supported, but VSJ will also look for its configuration parameters in a Java properties file, either bundled in the WAR file or outside the web app as a normal file in the host's filesystem. Tthe VSJ 3.2 'SanitycheckAuthenticator' tests a VSJ configuration by reading VSJ parameters from the properties file and then performing VSJ initialization, without requiring a Java app server.
The VSJ 3.2 'fatclient' example demonstrates a Java fat client (or "rich client", if you prefer) running on Windows using the client's Windows native Kerberos credentials to do SSO, per this thread: http://vintela.inside.quest.com/thread.jspa?threadID=4657&tstart=0 -- and no, I didn't prompt bhedrick to ask those questions, honest. The example also illustrates a Java fat client using a Kerberos credential-cache file (most likely on Unix/Linux) to do SSO, using the appropriate VSJ JAAS LoginModule and VSJ GSSAPI provider.
VSJ 3.2 supports audit logging (separate from debug logging), both for client logins and for URL accesses.
Under the hood, VSJ (Standard Edition) 3.2 incorporates the same improvements that went into the other 3.2 VSJ releases (WebSphere Edition, WebLogic Edition, JBoss Edition). In particular, the LDAP performance for resolving names of Active Directory groups is much better than it was in VSJ 3.1 and below.
http://www.vintela.com/vintela-single-sign-on-for-java-evaluation/
and from Quest Support.
What's new?
VSJ 3.2 adds support for LDAP queries to Active Directory (secured by Kerberos, of course). For the common case of retrieving LDAP attributes from the client's AD User object, VSJ 3.2 introduces a new API (the com.wedgetail.idm.simpldap.attributes.* package), illustrated by the new 'ldap' example, to simplify this case. For other LDAP scenarios VSJ 3.2 facilitates using the JNDI/LDAP/SASL code in JDK 1.4 (or above) with VSJ Kerberos credentials -- either delegated Kerberos credentials from the client or VSJ's own Kerberos credentials -- and the 'ldap2' example illustrates this.
VSJ 3.2 also adds support for mixed environments where some clients support SSO (SPNEGO or NTLM) but, for whatever reason, other clients cannot use SSO and instead must perform username/password login (normally HTML forms-based authentication). The new 'sso-and-forms' example illustrates this. This functionality addresses a scenario that a number of VSJ users have encountered in their environments, exemplified in this thread: http://vintela.inside.quest.com/thread.jspa?threadID=1924&tstart=0
VSJ 3.2 provides easier ways to configure VSJ and to test a VSJ configuration before VSJ-enabled web apps are deployed to a Java app server. In previous releases, VSJ only looked for its configuration parameters in the deployment descriptor (WEB-INF/web.xml). In this release that approach is still supported, but VSJ will also look for its configuration parameters in a Java properties file, either bundled in the WAR file or outside the web app as a normal file in the host's filesystem. Tthe VSJ 3.2 'SanitycheckAuthenticator' tests a VSJ configuration by reading VSJ parameters from the properties file and then performing VSJ initialization, without requiring a Java app server.
The VSJ 3.2 'fatclient' example demonstrates a Java fat client (or "rich client", if you prefer) running on Windows using the client's Windows native Kerberos credentials to do SSO, per this thread: http://vintela.inside.quest.com/thread.jspa?threadID=4657&tstart=0 -- and no, I didn't prompt bhedrick to ask those questions, honest. The example also illustrates a Java fat client using a Kerberos credential-cache file (most likely on Unix/Linux) to do SSO, using the appropriate VSJ JAAS LoginModule and VSJ GSSAPI provider.
VSJ 3.2 supports audit logging (separate from debug logging), both for client logins and for URL accesses.
Under the hood, VSJ (Standard Edition) 3.2 incorporates the same improvements that went into the other 3.2 VSJ releases (WebSphere Edition, WebLogic Edition, JBoss Edition). In particular, the LDAP performance for resolving names of Active Directory groups is much better than it was in VSJ 3.1 and below.