Shared authentication for web services

Question

Our company, Company A, may soon be partnering with Company B under some sort of licensing agreement. If it goes through, it will be necessary for users of Company B's web service to have access to Company A's web service. In other words, any user with an account for Company B's service should automatically have an account with Company A, but without having to create a new account...their's should be a shared account.

I'm not an expert in this matter (obviously) but I think this scenario would call for something along the lines of OpenID, but just between our two web sites. How would we go about sharing authentication is this way? I'm not familiar with the verbiage of the subject, which makes it difficult to google for guidance. Would this be a single-sign on?

Thanks.

Answer 1

I don't think OpenID is really an answer here. It matters very much how users of B's web service currently authenticate to these web services. I assume that they use username/password pairs, and assume that you want them to continue doing so even for A's web services.

If so, the next question is how the password gets transmitted and validated. I assume that B currently uses "Basic Authentication" (you need to confirm this with B). If so, authentication is straight-forward in principle: In an A web service, also use basic auth, which causes users to send their passwords to A, IN PLAIN TEXT. Use https to encrypt the passwords on the wire.

Then, having a copy of the password, validate them with B, e.g. by having A's service sending a request to some dedicated service at B which just confirms the password as correct.

The downside of this setup is that users have to reveal their passwords to A; by means of the licensing agreement, you need to establish trust that A won't abuse these password (i.e. that they will not store them, and not use them to incarnate a user outside of the agreed processes).

Answer 2

You have two problems, I think.

1. Allow Company A machines to authenticate Company B users (and vice versa?)
2. Provide resources on Company A machines for Company B users.

Single sign on, or any authentication solution like OpenID, solves the first part (and may be sufficient for static content); you still will need to actually create accounts or otherwise allocate resources on Company A machines for these now authenticated users.

For example, StackOverflow uses OpenID to authenticate users. This means that StackOverflow can leave the part of figuring out who you are to other services, such as Google or Facebook etc. However, StackOverflow still needs to create a local account for you, to track your reputation, send you updates to your questions, and other things.

For just the authentication part, here are a couple of options:

• If Company A already support OpenID, then Company B could just be an OpenID provider. You would still also want to add some code to Company A's website to ensure that a user logging in with OpenID is authorized, i.e., from Company B.
• If Company A and B both use LDAP (e.g. Microsoft Active Directory) to handle authentication for internally, then you can probably add a forwarder to have Company A query Company B's LDAP servers to authenticate users (subject to appropriate firewall tunneling).
• Or you can do it more statically, by having Company B provide a list of users, and having Company A pre-create accounts for all of those users ahead of time. This is the simplest but doesn't handle change of personnel from Company B very effectively, unless you set up an additional synchronization process. Here you would probably generate passwords (e.g., lastname+employeeID or random strings) for each account and have Company B distribute them to its users.

Answer 3

You're really describing federation here, of which OpenId is one example (albeit one that's not suitable in this case). With federated identity Company A allows Company B to authenticate their users. This authentication process results in a token from Company B containing information (claims) about the user which is sent to Company A and used for authorisation.

Federation is not single sign-on, that tends to describe the situation where Company A runs lots of services and an authentication service as well - and logging into the authentication service allows a user to access all of the resources without having to re-authenticate.

Without knowing what the architectures involved are it's hard to recommend an approach. The standard way to transport claims is in a SAML token. In a Microsoft environment you can use the Windows Identity Framework to write web services which understand SAML, and ADFS "Geneva" to issue SAML tokens from an Active Directory. There are similar solutions for other identity stores, such as IBM's Higgins.