From mail at jsfmp.com Mon Oct 20 19:38:15 2014 From: mail at jsfmp.com (Joel Shapiro) Date: Mon Oct 20 19:36:03 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... Message-ID: Hi all I've got a client using Active Directory for FM's External Authentication. They maintain AD Groups, and we use these accounts for both FMP & CWP logins. It all works well. They also use a service that's got a separate, non-FM web 'portal' that users log into with their AD credentials, using an LDAP server in the client's network. (I'll call this site ExternalSite) They would like to allow a user who's logged into ExternalSite to access their CWP site(s) without having to log in again through the CWP interface. (SSO) I don't know LDAP very well. Here are my thoughts: a) It seems to me that in order to log into the current CWP sites with authentication data from ExternalSite we'd need to get the password as well as the username so that we could hit the AD server and determine the user's AD Group. b) If we don't get the password from ExternalSite, we could potentially create a generic "web" account in FM and allow verified users to log in with that -- but then we woud not have access to their AD Group to determine their role, so it seems we'd need to maintain a User/Access table in FM (ugh). ExternalSite's IT says they *can* include the password in their hashed string but would rather not. Have any of you dealt with this before? Is it a bad idea to have ExternalSite include the password in their hashed string? Could there be a way to get something from ExternalSite and use that to hit the LDAP server again to somehow get AD credentials? (remember, I don't know LDAP well :-P) Any other thoughts/suggestions? TIA, -Joel From KFutter at sbc.vic.edu.au Mon Oct 20 19:53:28 2014 From: KFutter at sbc.vic.edu.au (Kevin Futter) Date: Mon Oct 20 19:49:51 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: References: Message-ID: I don?t really see how this could be made to work securely Joel. We have a similar set up at my workplace, where AD credentials mediate access to both FileMaker databases and any local web solution requiring authentication. Authentication to websites though happens entirely outside of FM; once credentials have been verified and group membership established (where relevant), access to the web resource is granted, and by extension, any content pulled out of FM. We have several sites that work like this, and I?d love to know a secure way of emulating an SSO-style scheme, so that once you?ve logged into one, you?ve logged in to them all. There are multiple web servers involved too, so it remains firmly in the too-hard basket for us. Kev On 21/10/2014 12:38 pm, "Joel Shapiro" wrote: >Hi all > >I've got a client using Active Directory for FM's External >Authentication. They maintain AD Groups, and we use these accounts for >both FMP & CWP logins. It all works well. > >They also use a service that's got a separate, non-FM web 'portal' that >users log into with their AD credentials, using an LDAP server in the >client's network. (I'll call this site ExternalSite) > >They would like to allow a user who's logged into ExternalSite to access >their CWP site(s) without having to log in again through the CWP >interface. (SSO) > >I don't know LDAP very well. Here are my thoughts: > >a) It seems to me that in order to log into the current CWP sites with >authentication data from ExternalSite we'd need to get the password as >well as the username so that we could hit the AD server and determine the >user's AD Group. > >b) If we don't get the password from ExternalSite, we could potentially >create a generic "web" account in FM and allow verified users to log in >with that -- but then we woud not have access to their AD Group to >determine their role, so it seems we'd need to maintain a User/Access >table in FM (ugh). > >ExternalSite's IT says they *can* include the password in their hashed >string but would rather not. > > >Have any of you dealt with this before? Is it a bad idea to have >ExternalSite include the password in their hashed string? Could there be >a way to get something from ExternalSite and use that to hit the LDAP >server again to somehow get AD credentials? (remember, I don't know LDAP >well :-P) Any other thoughts/suggestions? > >TIA, >-Joel > >_______________________________________________ >FX.php_List mailing list >FX.php_List@mail.iviking.org >http://www.iviking.org/mailman/listinfo/fx.php_list [http://www.sbc.vic.edu.au/assets/images/email_logo.gif] St Bernard's College Achieving Excellence By Learning And Doing Kevin Futter Webmaster Ph: +61392891095 | Mobile: Email: KFutter@sbc.vic.edu.au 41 Rosehill Road, Essendon, Victoria, 3040 | Ph: 03 9289 1000 | F: 9337 1741 | www.sbc.vic.edu.au ________________________________ This e-mail and any attachments may be confidential. You must not disclose or use the information in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. The College does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. The content and opinions in this e-mail are not necessarily those of the College. From mail at jsfmp.com Mon Oct 20 20:00:31 2014 From: mail at jsfmp.com (Joel Shapiro) Date: Mon Oct 20 19:58:18 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: References: Message-ID: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> Hi Kev, thanks for the reply. Do your website logins hit AD directly or an LDAP server? Do/can AD Group memberships get returned upon successful logins? -Joel On Oct 20, 2014, at 6:53 PM, Kevin Futter wrote: > I don?t really see how this could be made to work securely Joel. We have a > similar set up at my workplace, where AD credentials mediate access to > both FileMaker databases and any local web solution requiring > authentication. Authentication to websites though happens entirely outside > of FM; once credentials have been verified and group membership > established (where relevant), access to the web resource is granted, and > by extension, any content pulled out of FM. We have several sites that > work like this, and I?d love to know a secure way of emulating an > SSO-style scheme, so that once you?ve logged into one, you?ve logged in to > them all. There are multiple web servers involved too, so it remains > firmly in the too-hard basket for us. > > Kev > > On 21/10/2014 12:38 pm, "Joel Shapiro" wrote: > >> Hi all >> >> I've got a client using Active Directory for FM's External >> Authentication. They maintain AD Groups, and we use these accounts for >> both FMP & CWP logins. It all works well. >> >> They also use a service that's got a separate, non-FM web 'portal' that >> users log into with their AD credentials, using an LDAP server in the >> client's network. (I'll call this site ExternalSite) >> >> They would like to allow a user who's logged into ExternalSite to access >> their CWP site(s) without having to log in again through the CWP >> interface. (SSO) >> >> I don't know LDAP very well. Here are my thoughts: >> >> a) It seems to me that in order to log into the current CWP sites with >> authentication data from ExternalSite we'd need to get the password as >> well as the username so that we could hit the AD server and determine the >> user's AD Group. >> >> b) If we don't get the password from ExternalSite, we could potentially >> create a generic "web" account in FM and allow verified users to log in >> with that -- but then we woud not have access to their AD Group to >> determine their role, so it seems we'd need to maintain a User/Access >> table in FM (ugh). >> >> ExternalSite's IT says they *can* include the password in their hashed >> string but would rather not. >> >> >> Have any of you dealt with this before? Is it a bad idea to have >> ExternalSite include the password in their hashed string? Could there be >> a way to get something from ExternalSite and use that to hit the LDAP >> server again to somehow get AD credentials? (remember, I don't know LDAP >> well :-P) Any other thoughts/suggestions? >> >> TIA, >> -Joel >> >> _______________________________________________ >> FX.php_List mailing list >> FX.php_List@mail.iviking.org >> http://www.iviking.org/mailman/listinfo/fx.php_list > > > > [http://www.sbc.vic.edu.au/assets/images/email_logo.gif] > > St Bernard's College > Achieving Excellence By Learning And Doing > Kevin Futter > Webmaster > Ph: +61392891095 | Mobile: > Email: KFutter@sbc.vic.edu.au > 41 Rosehill Road, Essendon, Victoria, 3040 | Ph: 03 9289 1000 | F: 9337 1741 | www.sbc.vic.edu.au > ________________________________ > This e-mail and any attachments may be confidential. You must not disclose or use the information in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. The College does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. The content and opinions in this e-mail are not necessarily those of the College. > _______________________________________________ > FX.php_List mailing list > FX.php_List@mail.iviking.org > http://www.iviking.org/mailman/listinfo/fx.php_list From KFutter at sbc.vic.edu.au Mon Oct 20 20:29:42 2014 From: KFutter at sbc.vic.edu.au (Kevin Futter) Date: Mon Oct 20 20:26:04 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> Message-ID: We don?t have a separate LDAP server, as AD *is* effectively an LDAP server. When verifying credentials against AD, you basically have to bind against AD as that user, and if bind is successful, the user is OK, otherwise, the credentials are invalid. If bind is successful, AD returns all public attributes for that user, including group membership. IIRC, PHP?s LDAP functions convert this to an array, where you might have something like $user[?memberof?], which itself will be an array of group DN strings. I wrote a separate login script to handle all the AD stuff (which I really need to convert to a class!), and once it successfully returns some user data, I write the bits I need into a PHP session for that site. Since you can?t share these sessions across sites or servers (that I know of), it makes it difficult to share authentication state and data. The closest I?ve come to an idea about how to handle this is to create a proxy database in MySQL, query-able from anywhere on our local network, that houses authentication state and data for each resource for each user, and is queried first before AD. If current and valid login information is found in the MySQL database, then just set up their session as usual, else, query AD via LDAP for authentication. While I?m pretty sure I could make this work, it seems like a lot of work to solve what isn?t really a big problem, and could potentially introduce all kinds of security nightmares. Keeping auth state up-to-date and in sync could also be problematic. 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. Kev On 21/10/2014 1:00 pm, "Joel Shapiro" wrote: >Hi Kev, thanks for the reply. > >Do your website logins hit AD directly or an LDAP server? > >Do/can AD Group memberships get returned upon successful logins? > >-Joel > > >On Oct 20, 2014, at 6:53 PM, Kevin Futter wrote: > >> I don?t really see how this could be made to work securely Joel. We >>have a >> similar set up at my workplace, where AD credentials mediate access to >> both FileMaker databases and any local web solution requiring >> authentication. Authentication to websites though happens entirely >>outside >> of FM; once credentials have been verified and group membership >> established (where relevant), access to the web resource is granted, and >> by extension, any content pulled out of FM. We have several sites that >> work like this, and I?d love to know a secure way of emulating an >> SSO-style scheme, so that once you?ve logged into one, you?ve logged in >>to >> them all. There are multiple web servers involved too, so it remains >> firmly in the too-hard basket for us. >> >> Kev >> >> On 21/10/2014 12:38 pm, "Joel Shapiro" wrote: >> >>> Hi all >>> >>> I've got a client using Active Directory for FM's External >>> Authentication. They maintain AD Groups, and we use these accounts for >>> both FMP & CWP logins. It all works well. >>> >>> They also use a service that's got a separate, non-FM web 'portal' that >>> users log into with their AD credentials, using an LDAP server in the >>> client's network. (I'll call this site ExternalSite) >>> >>> They would like to allow a user who's logged into ExternalSite to >>>access >>> their CWP site(s) without having to log in again through the CWP >>> interface. (SSO) >>> >>> I don't know LDAP very well. Here are my thoughts: >>> >>> a) It seems to me that in order to log into the current CWP sites with >>> authentication data from ExternalSite we'd need to get the password as >>> well as the username so that we could hit the AD server and determine >>>the >>> user's AD Group. >>> >>> b) If we don't get the password from ExternalSite, we could potentially >>> create a generic "web" account in FM and allow verified users to log in >>> with that -- but then we woud not have access to their AD Group to >>> determine their role, so it seems we'd need to maintain a User/Access >>> table in FM (ugh). >>> >>> ExternalSite's IT says they *can* include the password in their hashed >>> string but would rather not. >>> >>> >>> Have any of you dealt with this before? Is it a bad idea to have >>> ExternalSite include the password in their hashed string? Could there >>>be >>> a way to get something from ExternalSite and use that to hit the LDAP >>> server again to somehow get AD credentials? (remember, I don't know >>>LDAP >>> well :-P) Any other thoughts/suggestions? >>> >>> TIA, >>> -Joel >>> >>> _______________________________________________ >>> FX.php_List mailing list >>> FX.php_List@mail.iviking.org >>> http://www.iviking.org/mailman/listinfo/fx.php_list >> >> >> >> [http://www.sbc.vic.edu.au/assets/images/email_logo.gif] >> >> St Bernard's College >> Achieving Excellence By Learning And Doing >> Kevin Futter >> Webmaster >> Ph: +61392891095 | Mobile: >> Email: KFutter@sbc.vic.edu.au >> 41 Rosehill Road, Essendon, Victoria, 3040 | Ph: 03 9289 1000 | F: 9337 >>1741 | www.sbc.vic.edu.au >> ________________________________ >> This e-mail and any attachments may be confidential. You must not >>disclose or use the information in this e-mail if you are not the >>intended recipient. If you have received this e-mail in error, please >>notify us immediately and delete the e-mail and all copies. The College >>does not guarantee that this e-mail is virus or error free. The attached >>files are provided and may only be used on the basis that the user >>assumes all responsibility for any loss, damage or consequence resulting >>directly or indirectly from the use of the attached files, whether >>caused by the negligence of the sender or not. The content and opinions >>in this e-mail are not necessarily those of the College. >> _______________________________________________ >> FX.php_List mailing list >> FX.php_List@mail.iviking.org >> http://www.iviking.org/mailman/listinfo/fx.php_list > >_______________________________________________ >FX.php_List mailing list >FX.php_List@mail.iviking.org >http://www.iviking.org/mailman/listinfo/fx.php_list [http://www.sbc.vic.edu.au/assets/images/email_logo.gif] St Bernard's College Achieving Excellence By Learning And Doing Kevin Futter Webmaster Ph: +61392891095 | Mobile: Email: KFutter@sbc.vic.edu.au 41 Rosehill Road, Essendon, Victoria, 3040 | Ph: 03 9289 1000 | F: 9337 1741 | www.sbc.vic.edu.au ________________________________ This e-mail and any attachments may be confidential. You must not disclose or use the information in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. The College does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. The content and opinions in this e-mail are not necessarily those of the College. From mail at jsfmp.com Mon Oct 20 23:01:27 2014 From: mail at jsfmp.com (Joel Shapiro) Date: Mon Oct 20 22:59:13 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> Message-ID: 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 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. From steve at bluecrocodile.co.nz Tue Oct 21 01:14:48 2014 From: steve at bluecrocodile.co.nz (Steve Winter) Date: Tue Oct 21 01:12:36 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> Message-ID: 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 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@mail.iviking.org > http://www.iviking.org/mailman/listinfo/fx.php_list Steve Winter +44 777 852 4776 steve@bluecrocodile.co.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20141021/7522c8a1/attachment.html From dale.bengston at gmail.com Tue Oct 21 13:16:16 2014 From: dale.bengston at gmail.com (Dale Bengston) Date: Tue Oct 21 13:13:58 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> Message-ID: <6E48377E-5286-4943-9A04-4D73DAA3DC96@gmail.com> Joel, I use and recommend adLDAP as well. Dale > On Oct 21, 2014, at 2:14 AM, Steve Winter 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 > 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@mail.iviking.org >> http://www.iviking.org/mailman/listinfo/fx.php_list > > Steve Winter > +44 777 852 4776 > steve@bluecrocodile.co.nz > > > > _______________________________________________ > FX.php_List mailing list > FX.php_List@mail.iviking.org > http://www.iviking.org/mailman/listinfo/fx.php_list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20141021/e896e1bc/attachment.html From mail at jsfmp.com Tue Oct 21 22:00:11 2014 From: mail at jsfmp.com (Joel Shapiro) Date: Tue Oct 21 21:57:56 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: <6E48377E-5286-4943-9A04-4D73DAA3DC96@gmail.com> References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> <6E48377E-5286-4943-9A04-4D73DAA3DC96@gmail.com> Message-ID: <92717A59-3BF0-4269-AF81-8553074868C8@jsfmp.com> Thanks Steve (and Dale) I'm checking now if we can get the AD Group memberships passed along through the LDAP server to ExternalSite. (Great idea, thanks!) 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? 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: 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 wrote: > Joel, I use and recommend adLDAP as well. > > Dale > >> On Oct 21, 2014, at 2:14 AM, Steve Winter 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 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@mail.iviking.org >>> http://www.iviking.org/mailman/listinfo/fx.php_list >> >> Steve Winter >> +44 777 852 4776 >> steve@bluecrocodile.co.nz >> >> >> >> _______________________________________________ >> FX.php_List mailing list >> FX.php_List@mail.iviking.org >> http://www.iviking.org/mailman/listinfo/fx.php_list > > _______________________________________________ > FX.php_List mailing list > FX.php_List@mail.iviking.org > http://www.iviking.org/mailman/listinfo/fx.php_list From steve at bluecrocodile.co.nz Wed Oct 22 02:00:07 2014 From: steve at bluecrocodile.co.nz (Steve Winter) Date: Wed Oct 22 01:57:48 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: <92717A59-3BF0-4269-AF81-8553074868C8@jsfmp.com> References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> <6E48377E-5286-4943-9A04-4D73DAA3DC96@gmail.com> <92717A59-3BF0-4269-AF81-8553074868C8@jsfmp.com> Message-ID: 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 wrote: > >> Joel, I use and recommend adLDAP as well. >> >> Dale >> >>> On Oct 21, 2014, at 2:14 AM, Steve Winter 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 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@mail.iviking.org >>>> http://www.iviking.org/mailman/listinfo/fx.php_list >>> >>> Steve Winter >>> +44 777 852 4776 >>> steve@bluecrocodile.co.nz >>> >>> >>> >>> _______________________________________________ >>> FX.php_List mailing list >>> FX.php_List@mail.iviking.org >>> http://www.iviking.org/mailman/listinfo/fx.php_list >> >> _______________________________________________ >> FX.php_List mailing list >> FX.php_List@mail.iviking.org >> http://www.iviking.org/mailman/listinfo/fx.php_list > > _______________________________________________ > FX.php_List mailing list > FX.php_List@mail.iviking.org > http://www.iviking.org/mailman/listinfo/fx.php_list Steve Winter +44 777 852 4776 steve@bluecrocodile.co.nz From cmoyer at moyergroup.com Wed Oct 22 04:52:58 2014 From: cmoyer at moyergroup.com (Chris Moyer) Date: Wed Oct 22 04:50:39 2014 Subject: [FX.php List] Re: [OFF] SSO from another site, via LDAP w/AD... In-Reply-To: <20141022035756.DC0F61A3A22C@mail.iviking.org> References: <20141022035756.DC0F61A3A22C@mail.iviking.org> Message-ID: <8758D15F-28A6-40E7-A903-E5FA1D87A8FE@moyergroup.com> I?ve had good success with SimpleSAML for SSO: https://simplesamlphp.org/ ******************************* Chris Moyer The Moyer Group Phone: 404-229-1127 http://www.moyergroup.com > On Oct 21, 2014, at 11:57 PM, fx.php_list-request@mail.iviking.org 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 > 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@mail.iviking.org >> http://www.iviking.org/mailman/listinfo/fx.php_list > > Steve Winter > +44 777 852 4776 > steve@bluecrocodile.co.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20141022/cc998180/attachment-0001.html From mail at jsfmp.com Wed Oct 22 11:25:41 2014 From: mail at jsfmp.com (Joel Shapiro) Date: Wed Oct 22 11:23:20 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> <6E48377E-5286-4943-9A04-4D73DAA3DC96@gmail.com> <92717A59-3BF0-4269-AF81-8553074868C8@jsfmp.com> Message-ID: Hi Steve On Oct 22, 2014, at 1:00 AM, Steve Winter wrote: >> 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. [JOEL] : Are you saying that we can get Group memberships for a user out of AD just from the username, even if we don't have the user's password? > 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. [JOEL] : The presenter was proposing them especially in contexts nowadays when one site/app needs to hit multiple servers Cheers, -Joel From mail at jsfmp.com Wed Oct 22 11:34:03 2014 From: mail at jsfmp.com (Joel Shapiro) Date: Wed Oct 22 11:31:42 2014 Subject: [FX.php List] Re: [OFF] SSO from another site, via LDAP w/AD... In-Reply-To: <8758D15F-28A6-40E7-A903-E5FA1D87A8FE@moyergroup.com> References: <20141022035756.DC0F61A3A22C@mail.iviking.org> <8758D15F-28A6-40E7-A903-E5FA1D87A8FE@moyergroup.com> Message-ID: <7E029541-B68E-40D1-84ED-A48647309490@jsfmp.com> Thanks Chris If we can't get the Group memberships otherwise, I'll look into both SimpleSAMLphp & adLDAP. Best, -Joel On Oct 22, 2014, at 3:52 AM, Chris Moyer wrote: > I?ve had good success with SimpleSAML for SSO: > > https://simplesamlphp.org/ > > ******************************* > > Chris Moyer > The Moyer Group > Phone: 404-229-1127 > http://www.moyergroup.com > > > > >> On Oct 21, 2014, at 11:57 PM, fx.php_list-request@mail.iviking.org 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 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@mail.iviking.org >>> http://www.iviking.org/mailman/listinfo/fx.php_list >> >> Steve Winter >> +44 777 852 4776 >> steve@bluecrocodile.co.nz > > _______________________________________________ > FX.php_List mailing list > FX.php_List@mail.iviking.org > http://www.iviking.org/mailman/listinfo/fx.php_list From steve at bluecrocodile.co.nz Wed Oct 22 11:45:11 2014 From: steve at bluecrocodile.co.nz (Steve Winter) Date: Wed Oct 22 11:42:55 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> <6E48377E-5286-4943-9A04-4D73DAA3DC96@gmail.com> <92717A59-3BF0-4269-AF81-8553074868C8@jsfmp.com> Message-ID: <63B525CF-DE39-4571-BA4E-6ABC4BED0C0A@bluecrocodile.co.nz> Howdy >>> 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. > > [JOEL] : Are you saying that we can get Group memberships for a user out of AD just from the username, even if we don't have the user's password? I am?! So long as you have another account which can bind to the AD, and which has sufficient privileges to perform queries. A while back I implemented a PHP-based system which was able to create and modify users within AD, which included performing queries to determine if the user already existed, which groups they were in, and making changes as required, either creating the user and then putting them in groups, or changing the groups they were in based on the newly requested permissions. If user you bind to the AD with (i.e. login with) is a member of the Domain Admins group, then they can perform queries. In my code (which extends adLDAP) I have this function private function _ldapAuth($get, $post, &$session) { $req = array('username', 'password'); try { $this->_validate($req, $post); return $this->user()->authenticate($post['username'], $post['password']); } catch (adLDAPException $ex) { throw new Exception($ex->getMessage()); } } Which logs in using a Domain Admin account, and results in the class variable $user being an authenticate user object. Then when I want to find out about another user I can do this private function _ldapUserInfo($get, $fields, &$session) { $req = array('username'); try { $this->_validate($req, $get); $info = $this->user()->info($get['username'], $fields); } catch (adLDAPException $ex) { throw new Exception($ex->getMessage()); } return $info; } Which results in the local variable $info containing details of the user identified by the ?new? username. And I also have private function _ldapListUserGroups($get, $attr, &$session) { $req = array('username'); try { $this->_validate($req, $attr); $list = $this->user()->groups($get['username']); } catch (adLDAPException $ex) { throw new Exception($ex->getMessage()); } return $list; } Which returns the list of groups which the username is a member of. Note that in the first two functions ?username? is the username of my Domain Administrator, but in the second two function username is the username of the person we?re interested in knowing information about. HTH Cheers Steve Steve Winter +44 777 852 4776 steve@bluecrocodile.co.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20141022/b7d3ac65/attachment.html From mail at jsfmp.com Wed Oct 22 12:11:06 2014 From: mail at jsfmp.com (Joel Shapiro) Date: Wed Oct 22 12:08:45 2014 Subject: [FX.php List] [OFF] SSO from another site, via LDAP w/ AD... In-Reply-To: <63B525CF-DE39-4571-BA4E-6ABC4BED0C0A@bluecrocodile.co.nz> References: <0D2E60A7-65FA-4C12-A186-19BDD7EFE1C6@jsfmp.com> <6E48377E-5286-4943-9A04-4D73DAA3DC96@gmail.com> <92717A59-3BF0-4269-AF81-8553074868C8@jsfmp.com> <63B525CF-DE39-4571-BA4E-6ABC4BED0C0A@bluecrocodile.co.nz> Message-ID: <3661965A-529A-42AB-98AA-6351CD6A397F@jsfmp.com> Wow. Who knew? ;-) Thanks Steve!! I now have less ignorance on these matters than I did two days ago. Thanks for the all the help. -Joel On Oct 22, 2014, at 10:45 AM, Steve Winter wrote: > Howdy > >>>> 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. >> >> [JOEL] : Are you saying that we can get Group memberships for a user out of AD just from the username, even if we don't have the user's password? > > I am?! So long as you have another account which can bind to the AD, and which has sufficient privileges to perform queries. A while back I implemented a PHP-based system which was able to create and modify users within AD, which included performing queries to determine if the user already existed, which groups they were in, and making changes as required, either creating the user and then putting them in groups, or changing the groups they were in based on the newly requested permissions. > > If user you bind to the AD with (i.e. login with) is a member of the Domain Admins group, then they can perform queries. In my code (which extends adLDAP) I have this function > > private function _ldapAuth($get, $post, &$session) { > $req = array('username', 'password'); > try { > $this->_validate($req, $post); > return $this->user()->authenticate($post['username'], $post['password']); > } catch (adLDAPException $ex) { > throw new Exception($ex->getMessage()); > } > } > > > Which logs in using a Domain Admin account, and results in the class variable $user being an authenticate user object. > > Then when I want to find out about another user I can do this > > private function _ldapUserInfo($get, $fields, &$session) { > $req = array('username'); > try { > $this->_validate($req, $get); > $info = $this->user()->info($get['username'], $fields); > } catch (adLDAPException $ex) { > throw new Exception($ex->getMessage()); > } > return $info; > } > > Which results in the local variable $info containing details of the user identified by the ?new? username. > > And I also have > > private function _ldapListUserGroups($get, $attr, &$session) { > $req = array('username'); > try { > $this->_validate($req, $attr); > $list = $this->user()->groups($get['username']); > } catch (adLDAPException $ex) { > throw new Exception($ex->getMessage()); > } > > return $list; > } > > Which returns the list of groups which the username is a member of. > > Note that in the first two functions ?username? is the username of my Domain Administrator, but in the second two function username is the username of the person we?re interested in knowing information about. > > HTH > > Cheers > Steve > > > > Steve Winter > +44 777 852 4776 > steve@bluecrocodile.co.nz > > > > _______________________________________________ > FX.php_List mailing list > FX.php_List@mail.iviking.org > http://www.iviking.org/mailman/listinfo/fx.php_list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20141022/019c8286/attachment-0001.html