On Mar 3, 2018, at 2:00 PM, Bob Miller wrote:
> In a different view of things (this wouldn't be SSO, but rather, using AD
> authentication) there some way that I could present a login screen, accept
> the user's ID and password, and send it to AD for authentication,
> receiving back a "Good" or "Bad" reply?
This defeats the whole purpose of “single sign on”. You log into your Windows
machine once, then never have to do it again for any program or server share
you want to use. You type your password in once and you are done with typing
passwords.
Now with a 4D application, I would also include a “Login” option in a menu or
somewhere for special use. For example, say you are an administrator and you
need to test something and want to log in as another user. The Login option
could present a dialog where you could select a user and enter a password and
that would switch you to be logged in as that user and give you the same
setting as that user. Then you could do your testing. But for the normal,
day-to-day operation users would never need to log in to the 4D database.
> How about the other question, since we're on a roll:
>
> I'm also not clear on what 'Current client authentication' does other than
> get the name of the
> current Windows user...
>
> What is the return value of 'Current Client Authentication' and what is it
> used for? Why won't this work unless the switch is turned on in 4D Server
> (since Win32api somehow can return the current user?)
What “Current client authentication” offers you the current Windows account
user name from a “trusted source”. Something you can count on as being
authentic. Consider this example:
Say you have your 4D database set up to use the “Current machine owner” command
to get the Windows user name that is currently logged into a machine. You use
that to set up permissions and what a user can do in the 4D database. That
works fine, but what about this situation…
Say a nefarious user knows the boss’s Windows login name — the one that is
returned by “Current machine owner”. He brings in his personal laptop to the
office and creates a user account on his laptop with that same login name. Then
he puts a copy of 4D Client on his laptop and connects to 4D Server. Bingo, he
is in the database with all the boss's privileges. All because you trusted what
“Current machine owner” reported.
The 4D SSO system uses the 4D Server machine to connect to AD. It will pass the
active Windows account login info — which is not just a user name — to AD and
say, is this a valid user login that you approved and provided. The guy with
his own laptop and a Windows account that he setup on his laptop will be
rejected by AD.
That’s how I look at SSO working and the value it provides.
Tim
Tim Nevels
timnev...@mac.com <mailto:timnev...@mac.com>
Innovative Solutions
785-749-3444
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
