Is the following scheme for sessions distributed over multiple services secure?

I'm developing a client/server application that will communicate over the Internet. The server does however consist of a number of distinct services, and I only want user to have to authenticate themselves once.

The scheme I have in mind for archiving this is having a central authentication service (over an encrypted connection where the identity of the server is authenticated first) that authenticates the user and generates a "large enough" session ID using a secure random number generator. For each service that the client needs to access from then on, it creates a new connection, authenticates the server (using certificates and SSL for example) and then sends the secure session id to prove that it is authenticated for the given session. The service contacts the centralized authentication service to verify that the session is valid and active before responding to any other requests.

Are there any disadvantages to this scheme compared to say using challenge/response on the session id or authentication cookies signed by the server? All s开发者_运维问答ervices are trusted, so there's no need to protect against a service (ab)using the session id of a connection to impersonate a user.

A major concern is that the client is in charge of transmitting the session id as a GET or POST request between servers, which makes this system vulnerable to Session Fixation. By this description it isn't clear how session state is being transfered or who is in charge of this information.

I agree that the cookie should be a very large random number called a Cryptographic Nonce. This variable is used as a key to access server side state. In the case of a distributed session the easiest solution is to have an individual server or database that can be made responsible for maintaining state across all domains. This makes things easier because a user can work on multiple domains simultaneously without the worry of race conditions. When a server needs to set or obtain a session variable they will make a request to the communal session server.

To transfer a user from one server to another without introducing a Session Fixation vulnerability is to create a one time use "Transfer Id", which should also be a Cryptographic Nonce. The communal server knows that a user has been flagged for transfer. The client browser transmits this "Transfer Id" to the new server, the new server looks up the user based on the "Transfer Id" and then the new server regenerate a session id to be used for that domain. One way method is to use a traditional session handler to insure that each server has a unique session id. The individual server can store state information to link this session id with a specific user's state on the distributed system.