| 1.1.0b2 |
July 23, 2010
This BETA 2 release of the 1.1 branch of the Jespa library includes the following significant fixes and improvements:
-
The API documentation has been significantly improved.
In particular, the
jespa.ldap package is now well documented.
-
Jespa now includes many sophisticated fully-functional examples.
All examples (in the
examples/ directory) have been re-written.
The API documentation has been greatly improved with many example code fragments.
-
The HTTP client could fail to report a non-200 status, it could incorrectly throw an exception trying to flush the output stream and it could throw a NullPointerException trying to close the output stream.
These issues have been fixed.
-
If authentication with the
HttpSecurityService failed (such as because the client tried to negotiate NTLMv1 whereas domain security policy required NTLMv2), it could incorrectly re-challenge the client in a way that caused a Not a Type 1 message error on the subsequent request. This error has been fixed.
-
The
LdapSecurityProvider could fail to correctly canonicalize and compare DN values if they included space characters around equals signs.
This provider could fail to properly compute a DN based on an RDN.
The issues have been repaired.
The special service.password.encrypted property is now removed when LdapSecurityProvider.dispose is called.
A warning is logged if GSSAPI authentication is used with the LdapSecurityProvider regarding the lack of proper DNS PTR records.
This provider will now throw an exception if the supplied password was NULL.
The LdapSecurityProvider will now retry to locate a suitable LDAP server if the supplied dns.site property did not connect to a suitable server.
The logic to retrieve account information (such as for the authenticate method) did not correctly process the search filter expression as advertised in the API documentation (the uid attribute was hard-coded into the filter).
Numerous other issues have been fixed in the LdapSecurityProvider.
-
The
LdapAccount.setPassword method did not correctly encode password hashes commonly used by RFC-based LDAP servers.
This issue has been repaired.
-
The
LdapAccount.changePassword method did not correctly catch the LDAP_CONSTRAINT_VIOLATION condition when trying to modify the Active Directory specific unicodePwd attribute.
This method also incorrectly modified state of the LdapSecurityProvider.
These issues have been fixed.
-
The
type, flags and conv members of the LdapAttrDef class are now public as advertised in the API documentation.
The 1.1 branch is still in BETA status and as such it is currently not recommended for production environments.
|
| 1.0.15 |
June 27, 2010
A deadlock in the Account.isMemberOf method (which is called by HttpServletRequest.isUserInRole) has been fixed.
Jespa would not properly failover gracefully to another DC if an "All pipe instances are busy" error occured (because of contrary server stickiness logic). This issue has been fixed.
The API documentation incorrectly included a class that was not intended to be public. This class is now properly excluded.
|
| 1.1.0b1 |
May 25, 2010
This is the first BETA of the 1.1 branch of the Jespa library. Some of the major new functionality included in this release is:
-
The security functionality defined by the SecurityProvider and Account interfaces have been expanded to include creating, updating, deleting, searching and querying accounts and setting or changing passwords on accounts.
-
The HttpSecurityService can now load properties from a properties file and will automatically reload the properties within 5 seconds if the file is modified at runtime.
-
An LDAP API is included which is designed to make performing common LDAP operations as simple as possible, efficient and with a minimal amount of code
-
A new complete LdapSecurityProvider may be used with other Jespa components like the HttpSecurityService.
The LdapSecurityProvider may be used to create, uptdate, delete, search and query Active Directory accounts and change or set Active Directory account passwords.
The LdapSecurityProvider also supports RFC-based LDAP servers such as OpenLdap.
-
The HttpSecurityService has been completely re-written to better support the ChainSecurityProvider, LdapSecurityProvider and other new functionality (although the 1.0 version of the HttpSecurityService is not known to have any significant issues).
-
An LdapSearch commandline utility is now included that permits any Java enabled system to query LDAP servers including Active Directory using NTLMv2 and 128 bit session security.
This eliminates the need for TLS / SSL and Kerberos (although both features are also supported).
-
A very complete example SecurityProvider with source code is included that illustrates how to build a SecurityProvider on top of an existing SQL database (the WordPress MySQL database in this case).
-
The Jespa Operator's Manual and API documentation have been completely revisited to reflect the major new functionality of Jespa 1.1 (only updated within the .zip and .tar.gz packages for now - the website will continue to host the 1.0 documentation).
Because this release contains a signifcant amount of new code, currently it is not recommended for production environments.
The 1.0 branch is very stable and will continue to be maintained indefinitely.
|
| 1.0.14 |
April 23, 2010
There have been no code changes in this release.
The Jespa Operator's Manual has been updated regarding HttpSecurityService excludes, the DNS records file, the service.acctname and localhost.netbios.name properties, the jar command, and new issues in the Possible Issues section.
|
| 1.0.13 |
March 26, 2010
If an HttpSecurityService client supplied incorrect NTLM credentials, the HttpSecurityService would return the expected 401 Unauthorized status but it would not challenge the client with the WWW-Authenticate: NTLM header. This is not consistent with the HTTP specification and it would prevent the password dialog box from reappearing. This issue has been fixed. The user will continue to be challenged with the password dialog until either correct credentials are supplied or the user clicks Cancel.
The HttpSecurityService logout feature using the http.parameter.logout.name parameter did not work correctly. It would not always properly remove security provider state from the HTTP session. This issue has been fixed.
|
| 1.0.12 |
February 11, 2010
The DNS records file now supports A records (in the format <name> A <ipaddress>) allowing a records file to completely bypass DNS lookups throughout the Jespa library. Under certain conditions, Jespa could attempt to lookup an IP address in DNS (such as when trying to use an IP address in an HTTP URL with the Jespa HTTP client). This issue has been fixed - a dot-quad address will be converted directly into an IP without attempting to communicate with DNS.
|
| 1.0.11 |
January 7, 2010
The NtlmSecurityProvider can now authenticate clients by userPrincipalName. For example, it is not uncommon to use the userPrincipalName attribute of an account for an email address with an SMTP domain and not the user's AD DNS domain. Previously Jespa simply failed to authenticate clients that supplied their userPrincipalName. This issue has been fixed. The Jespa Operator's Manual has been updated.
|
| 1.0.10 |
October 29, 2009
This release includes the following improvements and fixes:
- The HttpSecurityService excludes list now accepts wildcard expressions.
- The HttpSecurityService can now better suppress IE's network password dialog (in favor of redirecting to the fallback.location).
- Numerous problems with the HTTP client have been resolved.
- The HTTP client now automatically handles 301 and 302 redirects.
- All HTTP examples have been modified to use jespa.http.HttpURLConnection directly (using the java.protocol.handler.pkgs System property is clumsy and should not be used wherever possible).
- The "Property required" error message has been changed because it was believed to have encouraged operators to incorrectly set properties.
- Several types of shared objects are now gradually expired and disposed whereas previously they could accumulate and waste resources. They include SID cache entries, HTTP peers, HttpSecurityService authentication contexts and NETLOGON and DNS contexts.
- NETLOGON contexts are now indexed using a combination of the domain name and local NetBIOS name thereby improving the ability to safely share these contexts under sophisticated threading scenarios.
- The Jespa Operator's Manual has been updated significantly.
- Warning constants have been added to all undocumented public classes and interfaces to emphasize that undocumented APIs are not supported and may change without notice.
|
| 1.0.9 |
September 22, 2009
This release fixes the following issues:
- Failover did not work correctly. If the domain controller Jespa was communicating with suddenly became unavailable, exceptions could be thrown from the Jespa library and it could take as long as 5 minutes to correctly acquire a new domain controller. This issue has been fixed. It should now take no longer than 60 seconds for Jespa to recover from a domain controller failure and it should be completely transparent to users.
- The dns.servers property could be ignored in certain cases. This issue has been fixed. The Jespa library will only use the DNS servers supplied with the dns.servers property.
- DNS properties could not be changed at runtime. This issue has been fixed. If DNS properties are changed, new DNS contexts will be created as necessary.
- Windows 2000 clients could fail to authenticate using NTLMv1. This issue has been fixed.
- The service account password could be recorded in the log if it contained regular expression characters. This issue has been fixed.
- A carriage return in the license.key file could cause an ArrayIndexOutOfBoundsException. This issue has been fixed.
|
| 1.0.8 |
September 1, 2009
Error handling has been improved. Errors for conditions like an expired password, account lockout, invalid login hours, etc, will no longer result in an uncaught exception. These errors will now be quietly logged along with the account name.
NtlmSecurityProvider properties used by the NETLOGON service may now be changed at runtime without restarting the JVM.
|
| 1.0.7 |
August 14, 2009
The following error could occur if domain security policy does not permit "anonymous" binding to the NETLOGON service:
jcifs.smb.SmbException: 0xC0000199
at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:539)
at jcifs.smb.SmbTransport.send(SmbTransport.java:641)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:361)
The Jespa NtlmSecurityProvider no longer uses the "anonymous" identity when establishing Secure Channel and therefore this issue should be resolved. Note that this particular error code (which translates to STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT) can correctly occur under other conditions (such as the Computer account used by the NtlmSecurityProvider was not created correctly).
The following error could occur when using the explicit login feature of the HttpSecurityService in conjunction with some versions of IE which proactively reauthenticate POST requests:
jespa.security.SecurityProviderException: Not a Type 3 message.
at jespa.ntlm.NtlmSecurityProvider.acceptSecContext(NtlmSecurityProvider.java:1082)
at jespa.http.HttpSecurityService.doAuthenticate(HttpSecurityService.java:688)
at jespa.http.HttpSecurityService.doFilter(HttpSecurityService.java:782)
This issue has been fixed (although this particular exception can correctly occur under other conditions such as due to web server misconfiguration).
A NullPointerException could be thrown if DNS did not return any records (because dns.servers was not set and the default DNS server is not an authority for AD services). This issue has been fixed (Thanks MT).
The NtlmSecurityProvider did not always correctly handle the NTLMSSP TargetInformation. This isssue has been fixed (although it is unknown if this bug could cause an error with any real clients or servers).
|
| 1.0.6 |
August 3, 2009
Account information was incorrectly being written to the log. This log statement has been removed.
|
| 1.0.5 |
July 21, 2009
The MyNtlmSecurityProvider example did not work with Windows Vista clients. This issue has been fixed. Additionally, the domain name was required to be supplied in uppercase. This issue has been fixed but also requires upgrading to JCIFS 1.3.11. The explicit login form would not install the authenticated user's identity. This issue has also been fixed.
The Jespa Operator's Manual has been updated regarding validating the license key of a Jespa jar file, the NETLOGON service, JCIFS requirements and the ScriptPW.Password error running SetComputerPass.vbs.
|
| 1.0.4 |
June 22, 2009
The displayName account attribute (representing the user's full name) has been removed from the list of default Account attributes because it was discovered that the NETLOGON service always returns an empty string even if displayName has a value in AD. All references to the displayName / full name have been removed from the documentation.
|
| 1.0.3 |
June 17, 2009
The HttpURLConnection class has been modified to create an SSL socket if the protocol supplied in the URL is "https". The jespa.https.Handler URL protocol handler has also been added so that both NTLMv2 and SSL can be used together with other Java components as the default HTTP/HTTPS implementation.
The example webapp was accidentally distributed with the jespa.authority.dns.names.resolve init-param set to false and jespa.log.level set too high. This has been corrected.
|
| 1.0.2 |
June 4, 2009
The following error could occur sporadically:
jcifs.smb.SmbException: The parameter is incorrect.
at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542)
at jcifs.smb.SmbTransport.send(SmbTransport.java:644)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:372)
at jcifs.smb.SmbSession.send(SmbSession.java:235)
This error was due to a bug in the JCIFS library. All installations should be upgraded to use JCIFS version 1.3.10 or later which is available here:
http://jcifs.samba.org/src/
No logical changes to the Jespa package have been applied - only the JCIFS library must be updated. The Requirements section in the Jespa Operator's Manual has been updated to reference JCIFS 1.3.10.
|
| 1.0.1 |
May 1, 2009
The example webapp was accidentally distributed with an init-param for netlogon.useSecureChannel set to false. If you happen to be using the example webapp from 1.0.0 please remove this bad init-param or you may receive an error.
|
| 1.0.0 |
May 1, 2009
The BETA testing period is complete. No significant issues have been reported and no sigificant changes have been made in several weeks. IOPLEX Software is very grateful to all of you who have helped test what we hope will be a robust and useful solution.
The documentation has been updated slightly. A minor bug in the SecurityProvider.getAccount method has been fixed.
|
| 0.7.0 |
Apr 26, 2009
This release changes the HTTP session attribute name used to store security provider state to jespa.provider.state and sets Content-Type: text/html in the 401 Unauthorized response if the fallback.location feature is used. Neither of these changes should have any noticable impact on Jespa behavior although the old HTTP session attribute name (jespa.filter.provider.state) was documented as part of the API and therefore the minor number of the Jespa package has been incremented.
|
| 0.6.6 |
Apr 21, 2009
This release adds support to the HttpSecurityService for the Servlet container or a forwarding web server to supply a connection id using a header. See the new Obtaining a Unique Connection ID for the HttpSecurityService section in the Jespa Operator's Manual for details.
|
| 0.6.5 |
Apr 9, 2009
This release includes several new DNS failover capabilities including:
- Domain controllers will now be located using DNS SRV lookups.
- Multiple DNS servers can be specified. If a DNS server becomes unresponsive, Jespa will transparently failover to the next server.
- If Jespa cannot successfully communicate with a domain controller it will transparently failover to another domain controller (provided that the DNS SRV lookup returned multiple domain controllers).
- Active Directory Sites & Services is now fully supported - an AD "site" can be specified as a property.
- DNS queries are cached breifly to reduce redundant DNS traffic.
- A DNS "records file" may be used to bypass DNS SRV lookups.
No issues were reported with the last release and no additional "critical" enhancements remain. If you find any issues or feel Jespa is missing crucial functionality, please let us know about it.
|
| 0.6.4 |
Mar 24, 2009
Multiple concurrent requests could cause authentication state on the server to be incorrectly read or overwritten resulting in both "Not a Type 1 message" and "Not a Type 3 message" errors. This issue has been fixed. All connection state is stored using a unique connection id (note that if you are using mod_jk you must set JkEnvVar REMOTE_PORT - contact IOPLEX Software support for details).
IE8 and IE6 could proactively reauthenticate connections which could overwrite any explicit or anonymous login state used by the HTTP security filter. This issue has been fixed. The security filter will honor the authentication to satisfy the client but will maintain any explicit or anonymous login state.
If a group name cannot be resolved to it's SID, a warning will be logged. The documentation has also been updated regarding delays that can occur if a group name cannot be resolved.
All taglib dependencies have been removed from the HTTP security filter example webapp.
|
| 0.6.2 |
Mar 12, 2009
If the HTTP security filter init-params http.parameter.{username,password}.name were not set, a NullPointerException could occur. This issue has been fixed.
|
| 0.6.1 |
Mar 11, 2009
The Jespa Operator's Manual has been reorganized and generally improved throughout. There have been no changes to the software.
|
| 0.6.0 |
Mar 9, 2009
This release includes major improvements to the HTTP security filter and several bugfixes.
The minor version number has been incremented because the Filter class has been renamed to jespa.http.HttpSecurityFilter and the jespa.security.Domain class has been changed to an interface. There have also been significant additions to the API.
- The HttpSecurityFilter has been rewritten to support Windows group access control, form-based logins (and a corresponding logout feature), anonymous access, an excludes list and timestamps in the log file.
- The example webapp has been significantly reworked to exercise all of the new HttpSecurityFilter functionality.
- The HttpSecurityServletRequest object has been made public so that the developer can access the SecurityProvider used to authenticate the user and in turn access all of the information it offers (such as the user's full name).
- The SecurityProvider class now has a getAccount method that returns an instance of the Account interface which is a Map of properties and has an isMemberOf method for group based access control.
- The NtlmSecurityProvider getAccount method returns an Account with an implementation of isMemberOf that can very quickly check membership in Windows groups.
- The HTTP client did not include all of the basic HTTP request information. This issue has been fixed.
- The documentation has been significantly improved regarding the new HttpSecurityFilter functionality, browser settings and requirements for SSO. Several issues reported by users have been added to the Possible Issues section.
Thanks to everyone who supplied feedback.
|
| 0.5.4 |
Feb 16, 2009
This release includes the following fixes and improvements:
- Cross domain name canonicalization has been implemented. Specifically, using account name canonical forms 3 (backslash form) and 4 (principal form) will now work correctly with cross domain authentication. Prior to this release, if a domain name needed to be canonicalized, a jespa.security.SecurityProviderException: Cross-domain domain name canonicalization currently not supported error would occur.
- Jespa would incorrectly handle null and empty domain names (which indicate that the default domain should be used). This issue has been fixed.
- The getAuthType and getUserPrincipal methods of the HttpServletRequest used by the HTTP Filter have been implemented. Previously only getRemoteUser was implemented.
- The Jespa Operator's Manual and API documentation has been updated regarding changes to the MyNtlmSecurityProvider example, Windows Server 2008 and other changes.
- The log file could record the service account password. This has been fixed. Passwords will now be replaced with "********"
- If an error occured while authenticating the NETLOGON session, it would be incorrected reported as jcifs.smb.SmbException: NT_STATUS_SUCCESS. The correct error will now be reported.
Thanks to TLW, GT and AW.
|
| 0.5.3 |
Feb 4, 2009
An error in the ByteBuffer.encodeUint* methods could trigger exceptions like the following:
java.lang.ArrayIndexOutOfBoundsException: 128
at jcifs.util.Encdec.enc_uint16le(Encdec.java:59)
at jespa.io.ByteBuffer.encodeUint16le(ByteBuffer.java:229)
at jespa.ntlm.NtlmSecurityProvider._encodeObject(NtlmSecurityProvider.java:511)
at jespa.ntlm.NtlmSecurityProvider.exportState(NtlmSecurityProvider.java:574)
This issue has been fixed. Thanks NM!
|