Central auth service redirecting to subdomain, using digital signature as auth token

Question

I'm working on a "proof of concept" of a central auth service (not CAS). There are holes in my understanding of what I need to do, and I have concerns that the "protocol" is not secure.

Why/What

Users to land on a central auth server which performs credential verification, creation, and change. Once verified, the user will be auth'd for their correct subdomain and none others. E.g. Client Foo has several employees. The employees all login through the central server and are then sent to Foo's subdomain. The subdomains are for isolating large clients and for crude load balancing.

How

It is to operate like so:

1. User lands on https://www.example.com/login
2. User provides username, password, and subdomain (say, foo)
3. central auth service verifies credentials
4. Response contains sig (and a timestamp??)
5. User constructs a POST request to https://foo.example.com/login with relevant data, described later.

Signature

where sig is constructed thusly:

The document to be signed is user's ID and a timestamp in yyyyMMddHHmmss format joined with a comma. For example, for ID 55555 and timestamp 20140620132430, the document string is 55555,20140620132430.

The central server signs the documents with its private key. Each subdomain has the corresponding public key so they can verify that the signer was the central server.

POST Data

Relevant data passed to the subdomain's login (or auth??) service would be:

1. User's ID
2. timestamp for request generation time. Verified by receiver to be current.
3. Site (subdomain)
4. sig (base64 encoded -- not sure why that matters...).

It's not clear to me that the client/User is the one constructing the POST to the subdomain. The central auth server would of course have all relevant data to send to the subdomain and could construct the POST itself. Then I've got to deal with how to get the user over to the correct subdomain with the correct token or cookie or something.

Questions

1. Does this amount to "rolling my own" auth protocol?

2. Would an existing standard protocol cover my use-case?

3. What's wrong with the above? I keep thinking it's all wrong---that it's a potentially bad answer to the wrong question; that we should rethink what we're trying to use subdomains for.

4. If the basic idea is sound, am I missing anything? Or does anything else need clarification?

Answer 1

I've seen a scheme very similar to yours used in practice, although with shared secret MAC where you have public/private key. I wouldn't recommend it, seems cumbersome to me. Forgive me if I go to far, but seeing your results I think that you are not a server-side programmer. It appears that the server-side programmers of subdomains are your main Customer here - you want to help them with your central auth server. So I'd suggest to consult such a subdomain programmer and try to understand their needs and make your service super-easy for them (hint: the current one is not).

The major flaw is that this is expensive, both in terms of programming time (on central server and on subdomains) but also computationally.

Another major flaw is that when a timeout expires, some quite complicated code would be needed to allow user to re-authenticate and continue without loss of their state.

Re-think what your service does. My counter-proposition is that your service establishes a server-side state and gives it to subdomains so they can later use it internally. The state initially consists of user_id, authenticated_until, authorized_subdomains, but of course whatever non-trivial the subdomain does, it can add its own stuff to the same state.

In most frameworks that a subdomain could possibly use, the sessions are likely to be identified with a random token (think something like JSESSIONID or PHPSESSID).

Just one way to export a session from central-auth to subdomain is:

1. Subdomain exposes https://foo.example.com:21000 with IP restriction and both client and server certificate verification. This needs no programming, just webserver (virtual host) configuration tasks. User browsers and anyone else could never talk to this port.
2. A central-server POSTs to https://foo.example.com:21000 the state and a random token.
3. Now subdomain uses this very token for its normal session store.

I don't claim this is optimal, it requires less programming and less subdomain CPU than your design. Once you think of a session state, many possibilities and existing frameworks pop to mind.

---

Specific sub-answers:

1. You are proposing to create your own auth protocol.
2. I can't think of any existing protocol which answers your (wrong) use-case.
3. Yes, a "bad answer to the wrong question" I suppose.
4. Each HTTP request inside subdomain webapp where user is working requires some authentication. Not only the initial external HTTP request, but each one internal too. Nothing here would cause the timestamp/sig update when user is doing their normal work. After some minutes user is losing their state in a subdomain's webapp, whether user is active or not. They are losing their server-side session variables/objects. If you fix this and pass their session token via central-auth server, it nullifies all the other ideas; then you don't need your signature and proprietary public/private key computations in the first place.

Answer 2

One thing I can think of that may be problematic (if the user is POSTing to the subdomain) is that you don't sign the subdomain the user is trying to connect to. Let me try to give an example of the issue:

Let's say I have (valid) credentials for foo.example.com. I send (foo, username, password) to example.com/login and get back (sig=signed(id, timestamp)). Now I POST to bar.example.com/login with (id, timestamp, sig). bar.example.com/login will look at sig, verify that timestamp matches the signed data, and then log in the id that was signed. I'm now logged into bar.example.com. Oops.

So I'd say the not only need the user never see the sig, but giving the user the sig is actually a security issue. If you do send back sig to the user you need to do sig=signed(id, timestamp, subdomain) and the subdomain login needs to verify that it is the signed subdomain.

Answer 3

It seems as though the submit of user, pass, and subdomain is the only authentication that you are doing. Posting to the other domains does not seem secure to me at all. I've done this in various scenarios and to me the validation of user and password, no matter how this is done is the "authentication" service. If you want to segregate users into different subdomains, why not utilize the reverse proxy capability of essentially a single point of entry. And, this can also act as a load-balancer as well. I'm about 99% sure that you can accomplish your goals using a reverse-proxy server and do it very securely. I've done this for the state of North Carolina for one of the government entities.