I am building a single sign on mechanism between two sites for a client. For one, a Drupal site (and the client's main site), I control the code. The other is a proprietary membership database and front end maintained by a third party.
The way the single sign on works is that I have the user enter their email address and password (assigned by the member database, not by Drupal) when they log in to Drupal. The Drupal site then ignores Drupal's authentication mechanism and passes along the information to authenticate against the member database. It receives an authentication token, which it passes in the url to a page on the member database front end. That page uses the authentication token to set the login cookie for the user, then bounces the user back to the Drupal site.
So far so good.
Now, the membership database has a notion of a family, where there are one or more primary adults. Each member in the database has an email address, but only one (the primary adult) has a password and can log into the member area. This cannot be changed in the member database system.
The client wants to be able to allow separate logins to the Drupal site, where there is additional information that people with logins should see, and wants the secondary adult to use their separate login to access the member area.
The problem is that without modifying the member database system, the only way to accomplish this that I can see is to store member passwords on the Drupal side, associating two Drupal usernames and passwords (which each adult would use) with one member database email address and password (which would have to be associated with their Drupal logins on the Drupal end). I do not want to do this for security reasons.
SO: What I am proposing is this.
A secondary member in Drupal is associated, by a field holding the email address, with the primary login. When the secondary adult logs into Drupal, Drupal generates a token. The token is a one-way hash of the email address of the member login, combined with the current date and time. I get the vendor to create a page in the member database. That page will take the token in the URL and, on the server side, send a request to Drupal with the token and get back the email address of the user to log in. That page will then assign a cookie and redirect back to Drupal. The token will expire in one minute. For extra security, this service in Drupal will only accept connections from the IP address of the member database server.
Thoughts? Does this seem secure? If so, does it seem overengineered? Am I missing anything?