Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to be able to offer people who use my website, integration with their in-house authentication system (LDAP, I guess, since I don't want to limit it to a solution that only works for Windows users).

The goal is for a user to be able to log on to my website using their corporate user ID and password (or, even better, not have to log on at all, if they are already authenticated).

Sadly, I'm very ignorant of such things.

Is there a way to do this safely, and in such a way that each such integration isn't an enormous undertaking?

What pitfalls should I be aware of?

Are there any timeless resources on such topics that might be recommended?

share|improve this question

closed as off topic by womble, voretaq7 Nov 16 '12 at 3:44

Questions on Server Fault are expected to relate to server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

You question sounds more like a development issue than syadmin one. My recommendation would be to use the LDAP libraries provided by your framework, instead of rolling your own. – jscott Jul 26 '11 at 18:57

The solution you describe is basically Single Sign On. You should read up on Identity Provider initiated Single Sign On using SAML.

For vendors in the space, check out Ping Identity and Symplified.

SAML is non-trivial but it is the de facto standard for Enterprise SSO.

share|improve this answer
Thanks, this is helpful, both the vendor references and the mention of SAML. I'll read up on SAML (although voretaq7's answer gives a hint as to why a vendor might be useful vs doing myself). Thanks again! – Jake Jul 26 '11 at 21:39

You really don't want to do this - It will be nothing but pain and suffering for you.
Firewall rules at the remote sites will change and authentication will break. This will be your fault, even though you have no control over it.
LDAP schemas will evolve over time, and what was perfectly correct on Monday will be non-functional by Wednesday. Again, this is your fault (your site is broken, even though their changes are what broke it) and you'll be whined at to fix the problem.

There are also very few sane site administrators who would consent to giving you access to their user database. They are opening up a hole, restricted though it might be, and a sane admin would rightly resist doing so for the sake of a little convenience for the users.

If you want to offer a service like this you really need to be within their corporate network, and subject to its controls and restrictions (i.e. you'll be deploying hardware at their site). You'll then usually be integrating into their Kerberos domain, which allows already-logged-in users to use Kerberos tickets to authenticate to other services without having to enter their username/password.

share|improve this answer
Ok, a useful perspective, thanks. I think what I'm seeking is a secure way to do this, so that sane admins would be able to participate. But you're right, I know any integration like this exposes me to every kink introduced by the remote party. – Jake Jul 26 '11 at 21:41
With the exception of SAML as @jasondbecker mentioned (new one on me) all the "secure" techniques I can think of don't really have multi-tennant potential. SAML looks like a sound concept and may fit your bill assuming it's reasonably well supported. – voretaq7 Jul 27 '11 at 3:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.