On Jan 6, 2019, at 12:52 AM, Tom Benedict <benedic...@comcast.net> wrote:
> It doesn’t look like your scheme gets access privileges from Windows Active > Directory, instead you are getting them from your Users table. Is that > correct? No. I am getting access privileges by using the "Current client authentication” 4D command. I depend on that command giving me THE TRUTH. The truth begins with a valid Window Login Name. Once I have this string of bytes that define a user name I can rely on then that is something to authenticate with. Current client authentication = “timnevels”, then “timnevels” is a string of bytes I can rely on. So that is part one. Define “the truth”. > Do you also use 4D Users & Groups to define Groups to manage access to > application features? So you don’t use the LDAP commands to get 4D Groups for > the authenticated user? I could have used 4D Users and Groups, but I chose not to. I am using my own table based way to store allowed users and what they can do. I could have also chosen to build all the 4D User and Groups information into the Windows Active Directory system and then I would query using LDAP to see if the user name was allowed into the 4D database and what that user could do. You have fallen for the trap. I did the same thing until I realized that you have to trust something. The trap is to not break this into 2 parts. Who do you trust? And then what do you do with this trusted information? You need to separate 4D authentication into 2 parts: 1) getting a user name or identifier that you can trust. You can do it all yourself with 4D Users or your own [Users] table. Then you prove the user has authorization to use that user name by having them provide a password you can validate. Or you can trust someone else to do the password validation for a particular user name. That is what SSO is all about. You trust Windows Active Directory to validate a password for a particular Windows Login Name. I am trusting that "Current client authentication” 4D command gives me THE TRUTH. The truth begins with a valid Window Login Name. Once I have this string of bytes that define a user name I can rely on, then that is something to authenticate with. Current client authentication = “timnevels”, then “timnevels” is a string of bytes I can rely on. So that is part one. Part 2 is what you do with that valid user name. Once you have a valid user name, you can use whatever method you want to check permissions or privileges or groups that user name belongs to. You decide that. For me SSO is just user name and password validation. > Another question that comes to mind is why can't something similar to this > work under MacOS? Isn’t there an LDAP equivalent for MacOS? There probably is. I would connect with 4D and see if they have considered that. I’m sure they did, but probably decide not to implement it because Windows deployment is the majority of 4D’s user base. Also, the Windows Active Directory is a standard that is supported on ALL Windows operating systems. So only a single thing must be implemented and supported. Not sure what is guaranteed to be available on ALL macOS systems from versions with a macOS server, without a macOS server, just doing File Sharing, etc. I’m guessing there are many LDAP possibilities for macOS, but no standard and nothing guaranteed like there is on Windows OS. Tim ***************************************** Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ***************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
