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

[Steve Winter]

Hey Joel

> I'm checking now if we can get the AD Group memberships passed along through the LDAP server to ExternalSite.  (Great idea, thanks!)

Welcome :-) Even if they can’t provide you with that information, then you can find it yourself once you know who they are, by asking the AD for that information as part of your hand-over from ExternalSite.

> Why might I want to "use PHP to authenticate them against AD" instead of logging them in directly via FM's Ext. Auth. to AD?  Just to have parity with the SSO authentications, or for some other benefit?

No benefit particularly (and more work to implement than the already-working login using FM external authentication), other than the fact that it would mean that you could potentially have logic in your PHP which was based on knowing their role (which is almost certainly a moot point if this is an existing system ;-)

> Separately but somewhat related... Today I went to a session at html5devconf.com called "Death to Cookies, Long Live JSON Web Tokens". Not a solution to the issue in this thread, but I thought it was interesting:

JWTs are an interesting idea - I’m not sure they they’re going to be the death of cookies any time soon, but they are a nice way to obfuscate data being passed between sites, and more importantly verify that the data hasn’t been tampered with in transit.

Cheers
Steve


> 
> http://html5devconf.com/speakers/eugenio_pace.html#session
> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29
> http://jwt.io
> 
> -Joel
> 
> 
> On Oct 21, 2014, at 12:16 PM, Dale Bengston <dale.bengston at gmail.com> wrote:
> 
>> Joel, I use and recommend adLDAP as well. 
>> 
>> Dale
>> 
>>> On Oct 21, 2014, at 2:14 AM, Steve Winter <steve at bluecrocodile.co.nz> wrote:
>>> 
>>> 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/ 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
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>> 
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
> 
> _______________________________________________
> 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