[FX.php List] [OFF] SSO from another site, via LDAP w/ AD...

[Steve Winter]

Hey Joel

How ‘bout this for an idea - if ExternalSite can pass you a series of data fields about the user then they could pass you the groups the user is in, and by extension the role which the user has…

So now you know who the user is, and you know which role they have… at this point rather than a single generic FM account for web access, you could create a role-level generic account, which is used based on the role that the person coming to you from ExternalSite has (as passed through the hash) by your web code

For what it’s worth I concur with the reluctance of ExternalSite to pass the user password in the data passed - if for some reason you do decide to go down that route make sure that all communication between ExternalSite and CWPSite is over https.

For users who are logging in directly to your CWP site you could either use their credential for FM access (which does give you better record modification data) or you could use PHP to authenticate them against AD, (as if they had been authenticated on ExternalSite) and then still user the generic role-level accounts for CWP.

If you want to interact with AD using PHP then I’d highly recommend adLDAP from https://github.com/Rich2k/adLDAP/ <https://github.com/Rich2k/adLDAP/> which will make the whole process much smoother for you, rather than trying to ‘roll your own’...

Another solution which you could look at (which would require you to interact with AD) is that you could create a ‘master’ account on the AD which your code could bind to the AD server with (as Kevin mentions ‘binding’ is the way that you begin a connection with AD - essentially providing a valid username/password). If that account has sufficient privileges on the AD, then it can perform queries against the AD for information about other AD users, so rather than needing to pass the role information across from ExternalSite, you could get that yourself based on the user account passed from ExternalSite by asking it for it directly from AD.

Hope this helps some.

Cheers
Steve

> Hi Kevin
> 
> In this situation, I fortunately don't need to (fully) reinvent any wheels.  Your "another option" is actually what ExternalSite can make available to us - their "custom SSO":
> 
> "... pass-through authentication... The hash is a combination of a number of fields appended (concatenated) with a long, random alphanumeric key. This combined set of characters is then encrypted using an industry-standard cryptographic hash function such as MD5 or, for added security, Secure Hash Algorithm (SHA-1 or SHA-256). Alternatively, if the HMAC-SHA1 method is used, the shared key is instead used to ‘salt’ the hash."
> 
> So they can send us a hashed string to verify the user, but we'd need them to include the password (which they *can* do but recommend against) if we were to authenticate against AD to get the user's Group.  Otherwise, we'd have to "bypass the AD auth check" as you mention and just log them in with a generic FM "web" account.
> 
> ...
> 
> -Joel
> 
> 
> On Oct 20, 2014, at 7:29 PM, Kevin Futter <kfutter at sbc.vic.edu.au> wrote:
> 
>> Another option might be to pass some kind of encoded user token between
>> web resources, via GET or POST, but that’s probably even less secure, and
>> relies on you having control over the login functionality, as you’d have
>> to bypass the AD auth check. I gather you’re trying to automate it, rather
>> than bypass it.
> 
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list

Steve Winter
+44 777 852 4776
steve at bluecrocodile.co.nz



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20141021/7522c8a1/attachment.html