I have a requirement for a REST API that has token-based authentication: we will have replicated application servers with a load balancer, since tokens are generated by one server when a user is authenticated, and different requests from the same client can be handled by different servers, is there a generic technique or technology to share those tokens between the different servers?
About technologies, we will be using the Java stack, more specifically Grails.
About the application servers, we might have more than one database. This comment is important because discussing with colleagues, someone suggested to manage the token sharing using the same database from all application servers. I'm looking for a solution that doesn't need a centralized database, that let us scale on the DB side.
When using token based authentication, there's a server that authenticates the user and issues a security token. Authenticating the user can be done in many ways (verifying username/password against a database, verifying a certificate on a smart card etc).
Once the token is issued and signed by the authentication server, no database communication is required to verify the token. Any service that accepts the token will just validate the digital signature of the token.
The client (caller of your service) is responsible to send the token along with the request. So no matter which server behind your load-balancers handles the incoming request, it only needs the public key associated with the signing key to verify whether the request is valid.
Which security protocol to chose depends on the requirements you have. OAuth is used often for internet applications. WS-Federation and SAML-P are used a lot in enterprise environments.
As far as I see JWT (JSON Web Token) is supported in grails - it seems that this is what you're looking for. Basically you need to separate the authentication server as in this image. Authentication verifies the user/pass being sent and issues a token that is easily parseable without any further access to DB. To only thing that needs to be shared is the key that will be used to decode the incoming JWT. See, how it works.
Related
I'm writing a mobile app that communicates to a remote Java service via REST. I have protected my (SpringBoot) web service with https protection (due to the nature of the data, it needs to be secure) but my question is about which user/password I use to secure the https calls.
Should the username and password I use in the https header be a service account that the client (mobile app) and Java service knows or should it be the public user's username and password? The easiest option is just to use a service account but this means the mobile app will have those details built into it and distributed publically (albeit in compiled form).
Going the other way and using the user's username and password means I'll have to have the logon REST endpoint open and unsecure (which is fine I guess), but it just makes it slightly more fiddly.
Good question, and I would reckon you to use token based authentication and authorization scheme. Firstly you should have a login page where client logs in by providing username and password which is authenticated by calling some remote login service which maintains it's own user store or may use an existing one in your organization if any. Upon a successful authentication, the auth service should provide the client with a valid token, which then be refreshed time to time. The mobile or web client should pass in the token to the downstream microservices when a request is sent and this token should be sent inside the Authorization HTTP header.
Exposing the username and password while passing it around the network normally not considered as a good solution and that's where token becomes handy too. Token is the normal procedure that people use to secure rest endpoints. Yous rest endpoint should intercept each and every request comes at it, passes the token to the auth provider and verifies that. If the token is valid it will allow the request otherwise it should deny it.
Security is a pretty much larger topic and you have X.509 certificates other than tokens to encrypt the data sent across the wire over https and so forth. I suggest you to take a look at the spring security documentation since that will be a good starting point. Spring Security gives lots of hooks for developers which can be used out of the box with some sensible defaults. You can use JWT style tokens, Oauth tokens and spring security supports all these different forms too.
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.
My company is building a RESTful API that will return moderately sensitive information (i.e. financial information, but not account numbers). I have control over the RESTful API code/server and also am building the Android app. I've setup the API to use OAuth 2 with authorization code grant flow (with client ID and secret), and I auto-approve users without them having to approve the client since we own both client and provider. We use CAS for SSO and I am using this for the Authorization server as part of the OAuth 2 process when the user logs in to retrieve the token.
I am contemplating various ways to secure the data on the Android app. I've concluded that storing the client id and secret on the device is definitely not going to happen, but am thinking that storing the auth token might work, since it is only risk to the individual user (and really only if they happen to have a rooted phone).
Here are two options I have thought of. They both require me to have a sort of proxy server that is CAS protected, does the dance with the API server, and returns the auth token. This gets rid of the need for storing the client id and secret in the app code.
Here are what I've come up with:
1) Require the user to enter their password to access data each time they startup the App. This is definitely the most foolproof method. If this were done, I'd probably want to save the userID for convenience, but in that case couldn't use the CAS login (since it's web-based). I might be able to use a headless browser on the backend to log the user into CAS and retrieve the token based on what they enter in the Android form, but this seems hacky. Saving the userID is similar to what the Chase app does (if you happen to use this one) - it saves the userID but not your password between sessions.
2) Store the auth token on the Android device. This is a little less secure, but almost foolproof. When the user starts the app for the first time, open the webpage to the CAS login of the proxy server that returns the token (similar to https://developers.google.com/accounts/docs/MobileApps). After the user logs in and the token is returned to the app, encrypt it and store it private to the application. Also, use ProGuard to obfuscate the code, making the encryption algorithm more difficult to reverse engineer. I could also work in a token refresh, but I think this would be more of a false sense of security.
3) Don't use CAS but come up with another way to get an auth token for the service.
Any advice of how others have implemented similar scenarios (if it's been done)?
Thanks.
Well the reason why standards like OAuth are developed is that not everyone has to rethink the same attack vectors again and again. So most often it is your best choice to stick to something already available instead of baking your own thing.
The first problem with clients that are not capable of secretly storing data is that the user's data could be accessed by some attacker. As it is technically not possible to prevent this (code obfuscation won't help you against an expert attacker), the access token in OAuth 2 typically expires after short time and doesn't give an attacker full access (bounded by scope). Certainly you shouldn't store any refresh token on such a device.
The second problem is client impersonation. An attacker could steal your client secret and access your API in his own (maybe malicious) app. The user would still have to login there himself. The OAuth draft there requires the server to do everything it can to prevent this, but it is really hard.
The authorization server MUST authenticate the client whenever possible. If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses, and SHOULD utilize other means to protect resource owners from such potentially malicious clients. For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.
I think Google are the first to try another approach to authenticate a client on such devices, by checking the signature of the application, but they are not yet ready for prime time. If you want more insight into that approach, see my answer here.
For now, your best bet is to stay on the OAuth way, i.e. having the access token, client ID and client secrect (when using the authorization code grant flow) on the device, and configure your server to do additional checks. If you feel more secure obfuscating these, just do it, but always think of it as if these values were publicly available.
I need to figure out how to best authenticate users which are connecting from a C++ game client, against a mySQL database on another server, and I plan on writing a java web service to accomplish this.
Security is of primary concern, I need to make sure that the data flowing across the wire is encrypted, so I'll be leveraging SSL (originally I thought about message level encryption using ws-security however I think it's too much overhead).
What I really need to figure out is what kind of authentication mechanism I should provide. These users will be supplying usernames and passwords, and will be issuing a web request to a service.
I haven't decided whether the service should be a traditional SOAP web service or a RESTful one. The whole idea behind rest is to make the server stateless, and since the client will basically be establishing a session with the service, I don't see a point in using REST here.
Having said all that, what I really need to nail down is how exactly to perform the handshake and how to persist the session.
Are there any popular frameworks out there that provide APIs to do this against a mySQL database?
Again the client will offer up a UN / PW to the server, which needs to decrypt them (SSL should take care of that), authenticate them against the account info stored in a mysql DB, and then return some kind of hash or something similar so that the user's session can persist or the user doesn't have to log in anymore to issue additional requests.
Could anyone recommend a framework / some reading material for me to glance over?
Keep things as simple as possible.
HTTP is already stateless, and the idea of a login followed by a continued session is well established (session cookie). Use this paradigm and you won't have any troubles.
You also get the benefit of a very light-weight and open communication protocol and many good libraries for easy serialization / deserialization of common REST payloads like JSON or XML.
REST also means that you can use the same server with other clients quite easily.
I'd take a look at oauth:
http://developers.sun.com/identity/reference/techart/restwebservices.html
A well established pattern is:
1. log in & receive an oauth token
2. store token in db with user's internal id (and any other data such as token expiration time you wish to store).
3. send token to client, client persists token
4. client sends token for all future requests
5. server fetches user info from token
This method should work well with any client language and any backend datastore.
I would recommend to use REST. As authorization framework you can use standard container's jdbc or file realms on JAAS. If login/password pair is successful, store them at client side. After that, you can perform requests with auth credential supplied per request. I used jersey client for this. For [de]serialization from/to XML/json XStream library "do all dat math". Have a nice day.
I've created a RESTful server app that sits and services requests at useful URLs such as www.site.com/get/someinfo. It's built in Spring.
However, these accesses are password protected. I'm now building a client app that will connect to this RESTful app and request data via a URL. How can I pass the credentials across? Currently, it just pops up the user/password box to the user, but I want the user to be able to type the username and password into a box on the client app, and have the client app give the credentials to the RESTful app when it requests data. The client is built using Struts.
Cheers
EDIT - I don't think I made the question clear enough. I'm already forcing HTTPS, my question is more, in-code, when I'm requesting data from www.site.com/get/someinfo, how do I pass my credentials alongside making the request?
You more or less have 3 choices:
HTTP Auth
Roll your own protocol, ideally HMAC challenge/response based
OAuth
OAuth is currently susceptible to a variation of a phishing attack, one that is largely undetectable to the target. As such I wouldn't recommend it until the protocol is modified.
OAuth should also be a lesson about how difficult it is to design secure protocols, and so I'm hesitant to reccomend the roll your own route.
That leaves HTTP auth, which is likely best if you can use it.
All that said, almost everything on the internet uses form based authentication, and many don't even bother with https for transport level security, so perhaps simply sending the password text in the clear is "good enough" for your purposes. Even still I'd encourage using https, as that at least reduces the dangers to a man in the middle attack.
If you can add HTTP headers to your requests you can just add the Authorization header:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
where you're using basic authentication and the QWxhZGRpbjpvcGVuIHNlc2FtZQ== bit is "username:password" base64 encoded (without the quotes). RFC 2617
Well, https has nothing to do with authentication, it's just transport-level encryption.
if you interact with an HTTP api, be it that it's https or not, and the dialog box pops up, it means its using HTTP authentication, either basic or digest. If your client instantiates an http client to read data from those "services", then you can pass those credentials when you instantiate the object.
If you use client-side script, XmlHttpRequest supports http authentication as well.
So in terms of code, how you pass the credentials to the RESTful services is dependent on the http client you're using (the object you instantiate to retrieve the data). You can simply collect such a username / password yourself from the client, and use it to call the other service.
look at existing solutions. In this case, oauth