Barebones SSO Server Configuration

Barebones SSO Server Configuration


CubicleSoft presents… Barebones SSO Server configuration Alright, welcome back to the Single Sign On
Server and Client installation tutorial. We left off at the completion of the installation
of the Single Sign On Server. Let’s go ahead and get this configured. Let’s just get it
started! First off, we hit the Configuration page.
We need to make sure our timezone is correct, that our system clock looks correct, that
our clock drift is the way we want it – it dictates how long the absolute minimum session
length is for logins. As well, we configure other miscellaneous options such as the “No
Providers Message”. I personally like to throw in a little message that says, “@[email protected]
… If you believe this to be in error, contact …” Which will show up if someone is banned
as a spammer. It is possible for that to happen (a good thing) and it is nice to have a little
friendly message that lets them know that they have been banned for a specific reason.
@[email protected] provides more information on why the block happened. You don’t have to
set this up, I just like to do this because it is nice. The next step is to set up a nice blacklist
(so people can be declared as spammers). The documentation has this lovely little block
of text where you can copy and paste. I’m going to comment this out because I don’t
have a password for this particular DNSRBL. Basically, this says, “Hey, is the incoming
IP address banned?” And the response from the DNSRBL will come back as “Yes” or “No”.
It is useful to set up to keep spammers out of the system and your application. The next step is to setup an optional blacklist
based on geolocation. If you download and install a geolocation database that maps IP
address to the location in the world where that IP is located, you can get city, state/locality,
country, and other useful information. You can blacklist on that and/or you can map the
information to other fields, which I will get to fields and field mapping in a bit.
You could, for example, map the person’s city into their user account information. A little
creepy, but it is certainly possible. I’m going to save the changes and move onto
the next section, which is managing fields. What is a field? A field is something like
‘first_name’, ‘First name.’, and I get the option to encrypt the field or not. I’m not
going to encrypt this field but I will go ahead and plug in a couple of additional fields
and set a couple of them to be encrypted. ’email’, ‘E-mail address.”, and not going
to encrypt that. And finally, we’ll do ‘username’, [typing] ‘Username.’, and we’ll go ahead and
encrypt that. Alright, now I’ve got four fields and all
of these fields constitutes what a user account is made up of. So, I’ve got email, first_name,
last_name, and username. That is what a user account is in this system. The next step is to set up a provider. The
Single Sign On Server comes with a whole bunch of different providers. I’m going to install
the Generic Login provider. In order to install it, I have to make a decision up front and
this is very difficult to change later on, if not downright impossible. So, choose wisely.
I happen to like e-mail address and username, but whatever your needs are, select that.
I’m going to install this now. Now I have Generic Login installed with the default settings
and I am ready to configure it. The first thing to do is map Username because
Generic Login does not know what fields are in the database. It doesn’t understand what
a field is since it is just a string. As the server admin, I have to manually say map your
Username to a specific field in the user account when someone signs in. Username is now mapped
to ‘username’. Then I can blacklist specific usernames and there are other options related
to usernames as well that I can configure. I’m going to do the same thing (mapping) for
e-mail address. E-mail address support is a little bit difficult to set up because I
need to enter a subject line such as “Verify your account”. Then somewhere in the documentation
is a little blob of text that I can copy and paste. Plug in whatever information I want
there. Do the same thing for Recovery E-mail. “Recover your account.” Copy. And paste this
blob of text. Again, refining it however I want. There are lots of options as well related
to e-mail address and other settings. Regarding some of those settings, perhaps I want to
enable two factor authentication (2FA) and require every user to use 2FA. The defaults are usually a really good balance
between security and user-friendliness. There are many different modules that can be enabled
and have their own customizations for the server. Maybe, I want someone to sign a Terms
of Service agreement prior to signing up. So I can easily enable the module, press save,
and now this section gets an asterisk, which indicates more options. Expanding the module
options, I can now plug in the text of the Terms of Service and/or Privacy Policy or
a URL. There are other modules too: reCAPTCHA, rate limiting, etc. I really like the rate
limiting module. It prevents people from registering 500 accounts in one day, because that’s obviously
a spammer tactic. It keeps people honest and not abusing the systems that use the SSO server.
So I really like it and the defaults are actually pretty good. That is the Generic Login provider. One last
thing I have to do is, before I can install the Single Sign On Client, I have to set up
an API key. I’m going into Manage API Keys and then Add API Key to begin the process
of adding an API key to the system. First, I have to enter a namespace. It can be anything
(

About the author

Leave a Reply

Your email address will not be published. Required fields are marked *