This isn't too tricky, assuming both apps can access similar session data. But only if you can mess around with the code a bit. Since you're talking about different companies providing the software that second part might not be possible.
Basically when a session is started with AppA
the username/password is checked against some source (be it a database, IMAP server, LDAP server, whatever), this isn't actually the important part of the process for. After that first username/password collection, a session token is issued. AppA
checks the session token upon access and if valid; loads the session (so it doesn't require username/password every time you do something).
For this to work you need AppB
to (a) be able to access that session token (easy enough, it's likely stored as a cookie), (b) access the session data that lists valid tokens and the user's related (if user isn't included with the token in the cookie) and (c) create a session in AppB
without a username/password start, or validate against the existing session.
Session token access:
This should just be a matter of reading the cookies supplied to AppB
. As long as AppA
issues the cookie without a restrictive path
value (low risk since Company A can't know all the folders that AppA
could operate under).
Session data access:
Typically an application would store session information in some sort of a database table. The only trick might be learning the username associated with a session (the token might include username, or some sort of ID, or neither). Session validity as defined by AppA
should be obeyed by AppB
Create AppB Session:
Probably the trickiest part, if AppB
has dependency injection on the authentication module, (including session start, session detect and session terminate) then it's just a matter of getting the application to read the same session token as AppA
, compare/validate against the session data and translate and extend if required. Note unless both apps are modified you'll also want AppB
to defer logins and possibly logouts to AppA
Security:
If AppA
uses a cookie to store/retrieve session information without a path value notice that any other part of the same website can also see this cookie. If some of the site is served under http
- including images, style sheets and javascript - this session cookie will be exposed and obtainable by sniffing software (such as firesheep) or hardware. Serving static content from a different server (or same server under a different name) helps to mitigate this.