On Jan 5, 2019, at 2:00 PM, Robert wrote:
> Tim, I just toggled on the checkbox on the server that activates this feature
> but I’ve not implemented the code just yet…. So, how do you specify that you
> are logging in with the local 4D password instead of SSO? Modifier keys?
> Hidden Menu? Also, I’m not sure when the SSO login is in effect. Once the SSO
> code is in effect will you lock yourself out if the authentication server is
> down or you are developing on a different network without AD services?
Hi Robert,
You don’t want to use 4D’s password system directly. You can use it behind the
scenes so that you have access to “Current user” command as has been discussed
here at length. But for SSO to work, you don’t want the user to have to do
anything. They do absolutely nothing. So do not let them chose to use SSO or
not.
I would not plan on the authentication server every being down. That is total
death for a Windows network. That means NOBODY can log into any computer on the
network. So if the authentication server is down, accessing your 4D database
will be the least of their worries. They won’t even be able to boot their
computers or access network file shares.
One way to look at SSO in 4D is to boil it down to the implementation basics.
You need to identify the user automatically without any interaction from a
person.Who is trying to get access to my database? That’s it.
You can use “Current system user” command to get the name of the user that has
logged into the machine. On Windows OS this is the windows login name.
4D SSO implementation boils down to a single command “Current client
authentication”. Use that instead of “Current system user” command. This will
give you a guaranteed Windows login name that has been authenticated via
Windows Active Directory. This gives you reliable user identification.
Seems like people just can’t seem to get their heads around using 4D’s SSO
system to replace an existing authentication system. So i’m going to provide
some code that I use in my “Login” method. It is designed to use 4D SSO
implementation as primary authentication, but it also works without it and on
macOS. <>authenticatedUser_b is used in other areas of the application so that
I know if i used SSO to authenticate.
// get the Windows login name
$windowsUserLogin_t:=Current client authentication($domain_t;$protocol_t)
// check login validity
Case of
: (Is macOS) // running on macOS
$windowsUserLogin_t:=Current system user
<>authenticatedUser_b:=False
: (Not(Is compiled mode))
$windowsUserLogin_t:=Current system user
<>authenticatedUser_b:=False
: ($windowsUserLogin_t="") // an authenticated login could not be
retrieved
<>authenticatedUser_b:=False
// show user messasge and quit
Msg ("Unable to authenticate user and retrieve Windows Login
Name"+Char(Carriage return)+\
"Login Name: "+Current system user+Char(Carriage return)+\
"Domain: "+$domain_t+Char(Carriage return)+\
"Protocol: "+$protocol_t;"Error")
QUIT 4D
Else // got authenticated login situation
<>authenticatedUser_b:=True
End case
// look for user and load preferences and groups
If ($windowsUserLogin_t#"")
READ ONLY([Users])
QUERY([Users];[Users]WindowsLoginName=$windowsUserLogin_t)
If (Records in selection([Users])=1)
// save user name & ID
<>CurrentUserName:=[Users]UserName
<>CurrentUserID:=[Users]ID
// load preferences
LoadUserPreferences ([Users]ID)
// load privileges
GetUserGroups ([Users]ID;-><>CurrentUserGroupsA)
$loginSuccessful_b:=True
End if
End if
// display dialog of User to login
If (Not($loginSuccessful_b))
<>authenticatedUser_b:=False
OpenWindow (270;270;Movable dialog box;"Login";2)
DIALOG([Dialogs];"Login")
CLOSE WINDOW
End if
The above code first tries to use "Current client authentication”. If 4D Client
is running on Windows and 4D is configured to have SSO turned on — and it is
working — you get a $windowsUserLogin_t value. The remaining code deals with if
SSO is not available for use such as if you are not running compiled or are
running on macOS. Convenience code basically for my use when doing development
and testing.
Once you have a user login name you can depend on — that’s what SSO and the
“Current client authentication” command does for you — you can then check if
that user login name is allowed into your database. In my case I just check for
a record in the [Users] table.
The above code also handles the situation where authentication totally fails
and as a very last resort will display my old login dialog where the user can
select a user and type in a password. So far in over 5 months of SSO usage of
the 4D database it has never been used. (I have code that tracks its usage so I
know if someone has “sneaked in”. Nobody has. 4D SSO authentication has worked
100% reliably so far.
All of this code runs in the “On Startup” database method on 4D Client. No 4D
Server side code runs to take advantage of SSO with this implementation.
You will find examples in the 4D documentation — and in tech notes — about how
you can do this authentication work in the “On Server Open Connection” database
method. You can use that if you want, but I find it not necessary or useful.
You can do all your authentication work on 4D Client in the “On Startup”
method.
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
**********************************************************************
