My employer has setup round-robin LDAP load balancing. This is causing issues with my web application (Java / Spring) that do user creation / maintenance. For example, when a user registers, we will assign a temporary password and send them an email. If they are quick to login with their temporary password, the new user may not have synced to the other LDAP servers. This usually isn't an issue as the sync is faster than email and we can always add a delay before sending the email. What is the most troubling is when they login with their temporary password.
Here is how the application handles the temp password login:
User logs in with the temp password.
Spring's AccountStatusUserDetailsChecker throws a CredentialsExpiredException which we catch in our UsernamePasswordAuthenticationFilter. We send them to a password setting page prompting them for their new password. When they submit, we fire of the password change to LDAP and then attempt to reauthenticate them with their new password (we don't prompt them to reauthenticate, we just reuse the password they just submitted). However, it is quite likely that the password change has not propagated to all the LDAP nodes behind the load balancer. So, we go into a loop with a delay and retry the authentication. Normally this works just fine but when the synchronization between the servers is bogged down, we can actually end up locking them out of their accounts.
Has anyone ran into this issue? Any elegant workarounds (oxymoron?) that maintains the integrity of Spring Security (e.g. we don't want to totally hack the AccountStatusUserDetailsChecker to allow a user with expired credentials to get a valid Principal).
The guys who setup the company's LDAP infrastructure just suggested that we maintain our LDAP connection throughout the password change flow but they don't understand that doing something like this in a web app isn't advisable as you're just asking for connection leaks.
Related
Warning: This is an extremly long post, simply because I don't know how to explain our specific problems any other way (sorry).
Short version:
We are building a very modular suite of Java applications (both client and server side). Some clients have to authenticate against the servers, and the servers can authenticate against different types of user stores. Servers can also call other servers on behalf of their authenticated user, i.e. using their credentials. This has worked fine so far using simple username/password credentials, but now we have to optionally support SSO via Kerberos (and later other authentication systems). So far, we're failing (partly miserably).
Long version:
Our central Java library for handling principals is called User Access Layer (UAL). This library is used by both client and server applications and provides three types of funcationality:
Authenticate users based on their credentials (results in a failed authentication or basic information about the user, i.e. at least a login name or ID)
Perform principal queries
Perform principal modifications in the user store, if the backend supports it
(2) and (3) can be performed either using credentials specified by the caller or (if the backend supports it) as a technical user.
Actual access to the user store is handled by the configured backend. We provide a number of backends (LDAP, WebDAV, a custom JDBC database, a custom XML file) which can all be configured through a unified configuration file, usually named useraccess.xml. This file defines which backend (or backends) should be used and how it is configured, e.g. LDAP server and structure data for the LDAP backend or the database URL and database user credentials for the database backend. All backends implement the same interfaces so the application code is independent from the backends configured for a particular installation.
In our product, UAL is used by two different types of applications:
Clients (both command line/desktop clients and web frontend applications opened by a user in a browser). These applications use UAL to perform principal queries (e.g. our file browser application when modifying the ACLs of a WebDAV resource) or principal modifications (we have a web based user management application). Depending on the application, they get the credentials used for their UAL operations in one of the following ways:
a. User provides the credentials on the command line when calling the application
b. Application opens a dialogue and prompts the user to input credentials when a server access requires them
c. A login screen displayed when the user first accesses a web frontend application
Servers. which use UAL to:
a. Authenticate a user based on the credentials provided via the used protocol (e.g. HTTP/WebDAV or SOAP/WSSE)
b. Perform authorization for a user based on the user's (or the user's groups') attributes
c. Perform UAL operations (queries/modifications) on behalf of the client
d. Call other servers on behalf of the client, i.e. passing another server the user's credentials (e.g. via HTTP/WebDAV or SOAP/WSSE)
Until now, all our credentials were user name/password pairs, which worked fine as long as we made sure to keep these credentials in the user's session where necessary to later use them for accessing another server. We could do that every call that retrieved credentials or passed them to a server went through some of our code which could store/provide the necessary credentials.
Everything has become much more complicated with the requirement to support SSO via Kerberos. We've tried several approaches and modified our code base several times, but every time we believe to be on the right track, we realise that there's one spot we overlooked which cannot work the way we intended.
What makes things so confusing is that we have to handle credentials in several different ways. These are some of the ways we have to provide credentials to a server:
Via Apache HttpClient when accessing a HTTP/WebDAV server
Via SOAP/WSSE when accessing a web service
Via JNDI when accessing the LDAP server (in UAL)
And some of the ways we have to receive and verify credentials from a client:
As a login module in Apache Jackrabbit
When receiving a SOAP/WSSE message in one of our JAX-WS web services
A very common use case for us is the following:
Client calls server A via SOAP, providing credentials
Server A retrieves the credentials from the SOAP message and verifies them (responds with an error if they are invalid (authentication error) or the user is not authorized to perform the desired operation (authorization error))
Server A then calls WebDAV server B on behalf of the user, passing the user's credentials so that the WebDAV operation can be carried out with that user's permissions (and using that user's name and other attributes)
Server B retrieves the credentials from the HTTP message and verifies them
Server B then performs a principal query on the user store C, passing the user's credentials to the user store (depending on the configured UAL backend, this may simply compare the user's name and password to those in the user store XML file, or use them to establish an LDAP connection and query the LDAP store as that user)
And the problem is: There seems to be very little information on the internet to help with our specific problems. For starters, most resources simply describe how to setup a JAAS configuration file for a container to let its web applications perform user authentications. But our code has to run on both clients and servers and use one configuration file to specify the user store config for both authentication and principal queries/modifications. Furthermore, this has to work, with the same code, with user name/password credentials against a variety of user stores (some of them custom written) and with Kerberos (and later other) tickets against an LDAP server. And finally, it's not enough to have an authentication library which reliably tells us that user has provided the correct credentials (as many JAAS login modules seem to do), since we actually have to keep the user's credentials for further calls.
Since Apache Jackrabbit, which is the base for one of our core components, needs us to configure a JAAS login module, and there already are JAAS login modules for LDAP and Kerberos authentication, we have successfully modified UAL to perform all its authentication tasks via JAAS. For this we had two write login modules for our custom backends, and I had to implement my own LDAP login module since the default JAAS one would successfully authenticate the user against the LDAP server, but then throw away both the user's credentials and the LDAP context, so we couldn't perform further LDAP query using the same credentials. All our own login modules store the credentials in the authenticated subject's private credentials set, which is what JAAS's default Kerberos login module does as well. Using the resulting subject, we can then perform user queries. This works with all our backends and with both passwords and Kerberos tickets.
We were also able to modify our SOAP services to extract the credentials from the SOAP message. In the case of password credentials, we can simply pass them to JAAS when the authentication callback asks for credentials. However, there doesn't seem to be a way to do the same with a Kerberos ticket. Instead, our SOAP services currently handle those on their own, passing them through the necessary GSS API calls to verify the ticket, retrieve a matching ticket for the SOAP service's configured service user, and create a Subject containing the credentials and user information. Using this subject, we can then perform queries/modifications through UAL. However, this not only means that our SOAP services completely bypass UAL when authenticating Kerberos tickets, they also need some Kerberos configuration data (the service user name, the realm and the keytab file) in their own configuration, in addition to the useraccess.xml which already contains the same data (but not directly accessible to a generic UAL client because these settings are specific to the UAL LDAP/Kerberos backend). Obviously, things will only get worse when we add support for other ticket based authentication methods and they also have to be manually implemented in each SOAP service in addition to the UAL backend that actually handles the user store access.
Worst of all, we're still unsure how to get all this into our Jackrabbit based WebDAV server. Jackrabbit needs a login module, which should be fine for handling user name/password credentials but (as far as we can tell) fail for Kerberos tickets. We could probably fetch those manually from the HTTP headers, but that won't stop Jackrabbit from calling the login module and the login module from failing because it will still ask for a password and then fail to authenticate against Kerberos without one.
I can't shake the feeling that either our approach or (quite possibly) our understanding of how all these pieces should fit together is fundamentally flawed, but nothing we can find on the net spans enough of our requirements to indicate what we're doing wrong (or, more importantly, how it should be done to make it right). Because of the complexity of even describing our problems I so far shied away from posting this as a question, but if you've read this far and can give us any pointers on how to resolve this, you could save us from weeks of frustration.
You can remove everything after
Until now, all our credentials were user name/password pairs, which worked fine as long as we made sure to keep these credentials in the user's session where necessary to later use them for accessing another server. We could do that every call that retrieved credentials or passed them to a server went through some of our code which could store/provide the necessary credentials.
You problem is plain simple: you need credential delegation with Kerberos. The basic technique is quite simple. Since you have multiple problem areas here, I would recommend to break them up to have you problem solved:
OS/environment configuration for Kerberos credential delegation
How to request a delegable service token
How to retrieve the delegated TGT from the client
How to reuse the TGT from the client and request another service token
Since your inbound channel is HTTP, here are the answers:
If you are in an Active Directory environment, request your admin to set "trusted for delegation" on the machine account which will accept the GSS security context.
This is a bit tricky because it depends on the client language and library. In Java it is as simple as setting GSSContext.requestCredDeleg(true). Eloborate on the rest.
Inspect the code of my Tomcat SPNEGO/AD Authenticator library, I am extracting the client's TGT and storing it in the Principal implementation served by HttpServletRequest#getPrincipal method.
Assuming that your backend client library supports GSS-API properly, there are basically two ways to do it: (1) explicit credential usage: pass the delegated GSSCredential instance to the client lib and it should the rest. (2) implicit: Wrap your client action in a PrivilegedAction, construct a Subject with the private GSSCredential and invoke Subject.doAs with both. JAAS will use the implicit credential from the thread's subject and perform the operation on behalf of your user.
It seems like you haven't even reached point 2 or 3 yet.
We currently have 4 Spring applications that use Spring Security Oauth2 project for authentication. The applications are REST APIs that are consumed by other internal applications in the company I work for.
Everything was working fine in the development and QA environments as we were not doing load balancing, now that we are in pre-production we are facing an issue with the load balancer (LB).
This is the workflow for this issue:
Client sends request for the oauth token
LB redirects the request to Box 1
Box 1 authenticates and returns a valid Bearer Token
Client receives the token and store it for using through the sesion
Client sends request for a service in the REST API adding the previously retrieved token to the headers
LB redirects the request to Box 2
Box 2 fails to authenticate as it does not recognize the token and returns an Invalid Credentials response
We are using an in memory user store:
<bean id="tokenStore" class="org.springframework.security.oauth2.provider.token.InMemoryTokenStore" />
Is there a way to make different boxes to share the same token store? I know there is a JdbcTokenStore that can be used to persist tokens to the db, but I would prefer to avoid persisting tokens as these applications point to a legacy database that only stores business information.
I'm a bit late to this question, but maybe this will help someone searching for a similar answer. There are two major things you need to watch out for when using multiple oauth servers on a load balancer:
As #chris-h alluded to in his answer, you need to ensure that the information backing an access token issued by any of the oauth servers can be read (and trusted) by any of the other oauth servers. You can use a JDBC token store as he suggested, but this has the disadvantage that if Server A has to validate an access token issued by Server B, it always has to hit the database to do so.
A better solution (IMO) is to use JWT access tokens, where all the information needed to validate the token is encrypted within it. So long as all oauth servers use the same encryption key, they can read the data in each other's access tokens and trust that the data is valid since it is encrypted. The advantage is there are no database calls needed to validate an access token. The disadvantage is that there's no easy way to invalidate an access token once it's been issued. If you ever wondered why refresh tokens are needed when you could just increase the expire time of the access tokens themselves, this is the biggest reason.
The second thing to be aware of is that the Spring oauth implementation uses sessions to keep track of where the user is an the authentication process. If you aren't careful, you could wind up in an "endless loop" scenario. Suppose you have two oauth servers--Server A and Server B:
The user goes to a web page or service which requires authentication, so gets redirected to "foo.com/oauth/authorize". The load balancer sends this request to Server A.
Since Server A doesn't have any session information which proves the user is already authenticated, it redirects the user to the login page at foo.com/oauth/login. The redirect goes back through the load balancer, and since the load balancer is working in a "round-robin" fashion, this time it sends the request to Server B.
The user logs in successfully, so session information is written to keep track of this. This session information is only known to Server B.
Since the login was successful, the user gets redirected back to "foo.com/oauth/authorize" to continue the authentication process. Once again the redirect goes back through the load balancer. Since the load balancer is working in a "round-robin" fashion, this time it sends the request to Server A. But Server A doesn't know about the successful login that happened on Server B. Go back to step 2!
Probably the best (current) solution to this problem is to ensure that your load balancer supports "sticky sessions"--that is, once it sends a particular user to Server A or Server B, it always sends that user to the same server for a while.
A better solution might be for oauth implementations to not use sessions at all. Instead, use encrypted data passed as a parameter to /oauth/* that denotes where you are in the login process. Similar to how JWT tokens work, the information can be trusted by all servers if they all share the encryption key.
All authentication servers and all resource servers must share the same tokenStore in order to validate tokens.
That means switching to the JdbcTokenStore or a custom TokenStore implementation which is capable of sharing tokens between servers in some way (shared datastore, NFS shared filesystem, etc.). Of course, it may even be possible to share an InMemoryTokenStore using Terracotta or a similar memory-sharing product if you are willing to go that route.
Specifically for implementing authorization code grant to work with load balancer I stored Spring sessions in Redis. Redis being a shared resource ensures Spring session information is shared among all the running instances of the Spring application.
There is an alternative approach evaluated by having sticky sessions in place at load balancer which is also a good option but this implementation requires session replication in order to maintain HA.
Sticky Sessions
IMHO Centralized cache store implementation gives more control at the application end having all configurations at the application with guaranteed HA without any additional overheads.
With Cache Store
Below is how the sessions are stored in Redis
application.properties
spring.session.store-type=redis
server.servlet.session.timeout=3600s
spring.session.redis.flush-mode=on-save
spring.session.redis.namespace=spring:session
And for overriding HttpSession management
#Configuration
#EnableRedisHttpSession
public class HttpSessionConfig extends AbstractHttpSessionApplicationInitializer {
#Bean
public JedisConnectionFactory redisConnectionFactory() {
...
JedisConnectionFactory jedisConFactory = new JedisConnectionFactory(redisConfig);
...
return jedisConFactory;
}
}
I'm working on a web application for internal use that is driven by many web service requests to another remote server. The internal site maintains its own session, authenticated by username/password credentials that are themselves backed by the web service(i.e. we make a remote authentication call to verify the login to the internal site). The web service requests also require authentication using these same credentials.
We were hoping these web service requests could remain stateless, which means passing the credentials in with every request for authentication. The problem is remembering the credentials to be used(the ones entered during the initial login) in a way that is secure. I'm not aware of any truly safe way to store a password for later re-use - hashing it would sacrifice our ability to use it again. The best we could do would be to encode it in the session scope and hope that no malicious developer will ever try to catch it in a thread dump or something.
Is there a better solution to this that I'm missing? Am I being overly paranoid about the risk of storing an encoded password in memory, or is our approach to this project flawed?
i would suggest to use token based authetication, a token is passed to the user for cheap user verification on the fly. One implementation of this would be to generate a cookie that is passed to the user for session management.
i have not used but you should look at oauth may be example
Ultimately our conclusion was that no, storing user credentials on the server that are re-usable in any way is not safe, so we can't do truly stateless re-authentication on each web service request. We simply had to compromise and preserve a stateful connection that is initiated and stored during the user's initial login.
I have some java code which allows users to reset their passwords stored on a LDAP server. The code runs as part of a web application running on Glassfish.
The problem I'm seeing is that after calling the change password operation, the user can subsequently use either password to access the application.
I have a unit test which runs directly against the LDAP server and I can verify that the password did indeed change and the user cannot gain access using the old password. The problem is not on the LDAP server.
What I've noticed is that if I restart Glassfish after the password change operation, only the new password is valid (as expected). I'm guessing that Glassfish is caching the credentials somewhere.
What do I need to set in Glassfish (or maybe in my web.xml) to either
tell Glassfish not to cache the LDAP credentials
reset the Glassfish password cache
Thanks in advance....
UPDATE
Still having this problem. I also thought that the browser could be storing this information, but that doesn't seem to be the case. I close out of my browser session and both passwords still work in the new session - even with different types of browsers. BTW - I don't know if it matters or not, but this is HTTP basic authentication.
UPDATE
We are also using the single sign on functionality included with Glassfish. From this article, it looks as if the session is tied to a cookie on the browser and maybe the user would be valid until the cookie expired? It looks as if the cookie is tied to a session. Getting closer to figuring this out....
Try adding this property to your ldap realm's additional properties:
com.sun.jndi.ldap.connect.pool=false
Could be your problem related to this Active Directory issue?
http://support.microsoft.com/?id=906305
My problem was.
A user is accessing a restricted web application with JAAS (on Glassfish 2.1). LDAPRealm is used, and authentication is successfully performed from LDAP. A password policy should be installed for the users, so that they are forced to change passwords, have passwords of certain complexity/length, password failures and last N passwords should be checked. Password policy of LDAP server used (OpenDS) supports all this, but it is not obvious at all how to receive this kind of information in JAAS FORM login we are using, so that the information (i.e. "Please change you password") can be displayed to the user.
Do you have any ideas how to go about implementing this? Using database only is not an option, users need to be in LDAP. What is not obvious is whether to use LDAP password policies at all, or have it all programmed in our web application. I would like to avoid this and use LDAP's native password policies.
Thank you for answers and best regards,
Bozo
Unfortunately, what you can do using JAAS is kind of constrained to a small set of operations that any login system can support. While LDAP supports a password policy, other login systems (eg keystores) may not, so JAAS cannot have code that requires this.
Hence, you'll have to talk to the LDAP server directly using either JNDI or possibly this library from Novell.
Got it. Have to use a SAM, since you cannot receive LoginException (with reason of login failure) in the existing auth mechanisms in Glassfish.
Answer is here: How to override j_security_check in glassfish?