I am interested in SSO (Single Sign On) and have tried various SSO services. I am completely new to SSO, so here is a brief summary of what SSO is and how it works, and how easy it is to use.
motive
I use various web services, each of which has its own ID and password, and I can't remember them all, not very well, so I write down my IDs and passwords.
Furthermore, if there are multiple accounts for the same service, it is very cumbersome to switch accounts.
Also, one account may be shared by several people, and it is a hassle to re-set the password when the person who shared it leaves.
I heard that SSO (single sign-on) is a good solution to these problems, so I tried various methods.
What is SSO (Single Sign-On)?
SSO (Single Sign-On) is a mechanism that allows users to log in to multiple services with only one ID and password.
There are many different methods, but my goal was to be able to log in to a web site/service with a single ID and password, We tried something called IDaaS (Identity as a Service).
How IDaaS works (SAML)
It was similar to the web services that often allow users to register with a Google or Facebook account.
reserve
First, there is a core, user database service (IDaaS) that creates and manages user IDs and passwords, and allows you to create an account there and log in. (The user ID here is the IDaaS user ID, not the user ID for the web service you want to use.not (verb-negating suffix; may indicate question or invitation with rising intonation)(Note that the)
Then, create an account for the service you want to SSO.No password is setand set up IDaaS to listen for authentication inquiries.
Login
When you try to log in to the service you want to SSO, the login screen for that serviceinstead ofThe IDaaS login screen will open.
There, enter your ID and password for IDaaS, and you will see an agreement screen.
Then, once you agree, you can log in to the service you wish to SSO.
It's that flow you often see when logging in with Google or Facebook authentication.
Strictly speaking, Google accounts and Facebook use OAuth2.0 authentication, and IDaaS uses SAML authentication, a specialized authentication for SSO purposes, but the flow from the user's perspective is similar.
Usage (user side)
From the user's point of view, the way to log in to the service is
- How to log in to the service directly from the URL
- How to log in from the IDaaS portal site
There are two ways to do this.
Log in directly from URL
The aforementioned method of trying to log in by directly specifying a URL to the service brings up the IDaaS login screen, from which you log in.
Indirect login through the portal
Instead of accessing the service directly, you can also access it through the IDaaS portal site.
First, when you log in to the IDassS site, you will see a row of icons on the portal screen for the site you want to SSO.
If you click on the icon for a service, the site for that service will beWhile logged inIt will be opened.
How IDaaS works (form)
The method using SAML cannot be used unless the service you want to SSO supports SAML.
An alternative method when SAML is not available is to use "forms".
reserve
First, install the browser plug-ins and extensions provided by IDaaS on your browser.
Login
Log in to the IDaaS portal site.
Clicking on the service icon will bring up the service login screen.
Then, the user name and password will beAutomatically populated.You will be logged in automatically.
It seems that user IDs and passwords are stored on the IDaaS server, and the browser plug-in brings that ID/password information and fills in the information automatically.
I don't know how it works, and I can't say anything about whether it is safe from a security standpoint, but all IDaaS offer this feature and it is probably safe....
SSO is not for personal or field service
The IDaaS side of the story
IDaaS is an enterprise product, not for individuals.
When you register for IDaaS, an organization is first created and you are registered as its administrator. Then, users are created and added to be managed by the organization.
The service was not designed for personal use, such as registering only one account for one individual and using that account as a key to register the services you want to SSO.
The service side of registering with SSO
Also, if you are doing SAML authentication, the service you register for SSO must also be an enterprise account.
That is because only the organizational administrator of a service can authenticate an account for a service that he/she wants to use to SAML.
What this means is that an individual Google account cannot be SAML-authenticated. On the other hand, with G Suite, the corporate version of Google accounts, an administrator of that organization can set individual G Suite accounts of that organization to SAML authentication. (Even if it were functionally possible to SAML-authenticate a personal Google account, only Google, which manages Google accounts, could do so.)
In another example, an Amazon account for an e-commerce site cannot be SAML-authenticated because it is a personal account, but a corporate Amazon business account can be SAML-authenticated because the organization manages the account.
Other services such as Twitter and Facebook do not have SAML authentication because they only have stray accounts. It is best to assume that personal services cannot have SAML authentication because the administrator is the provider of that service.
In other words, the main uses of IDaaS are
Allow organizations to SSO the users they manage to external services that they also subscribe to.
It is not suitable for personal use or for SSOing to a stray account.
However, if you do not want to use SAML authentication, you can SSO into a stray account using the aforementioned form-based login.
Sharing an account with multiple users
The service you want to SSO is,Users registered for that serviceauthentication to IDaaS, but does not know who the IDaaS user is.
So, an account for one service you want to SSO can be shared by multiple IDaaS users.
Conversely, multiple accounts for the same service you want to SSO can be assigned to a single IDaaS user, and you can switch between them to log in.
I think this is one of the advantages of using SSO services because these situations do exist.
Linkage to main user ID and password
I assume that your organization uses Active Directory or other means to centrally manage user IDs and passwords.
I would like to use those IDs and passwords to log in to IDaaS as well.
For this purpose, IDaaS provides a relay application.
Set up a relay application between the user management DB, such as Active Directory, and IDaaS.
Then, when logging into IDaaS, IDaaS will query the user management DB via the relay application for the user ID and password, and the user can log into IDaaS using the user ID and password in the user management DB.
So, you mean to allow SSO to the IDaaS itself.
Main SSO Services
From my research, the following four seemed to be the major ones. At first, I tried all of them except G Suite.
- OneLogin
- Okta
- Azure Active Directory
- G Suite
Independent Department
For independent IDaaS services, the two choices are OneLogin and Okta.
I have used both OneLogin and Okta, and my impression is that Okta has slightly better features, but its fees are higher.
It is difficult to compare IDaaS by function since all IDaaS offer a set of features.
User management DB system
As mentioned above, eventually IDaaS will also query user IDs and passwords to user DBs such as Active Directory, In fact, the user DBs "Azure Active Directory" and "G Suite" themselves provide SSO functionality.
I don't know about "G Suite" because I have never used it, but "Azure Active Directory" has the same SAML and form authentication features as the above IDaaS.
My impression was that the connection between multiple SSO accounts and multiple IDaaS was weak, and that the management functions and ease of use for the administrator were more sophisticated and easier to use than those of independent IDaaS.
Azure Active Directory" and "Traditional Active Directory"
Azure Active Directory" and "traditional Active Directory" are the same as "Active Directory" in name, but they are completely different.
Traditional Active Directory is a user database server that manages users logging into Windows and is installed and operated primarily on-premises.
Azure Active Directory, on the other hand, is a user database service that, like IDaaS, manages users over the Internet, and Office365 users are managed here.
So, in order to make the user IDs and passwords in "Azure Active Directory" the same as the user IDs and passwords for logging into Windows, it is necessary to synchronize them with the "traditional Active Directory" as with independent IDaaS, and tools for this purpose are Microsoft provides a tool for this purpose.
Charge
The fee is roughly 500 yen to 1,000 yen per user per month.
The price will vary depending on how the security provisioning option is added.
provisioning
IDaaS can also be described as a service that ties the authentication of multiple other service accounts to the main user registered with IDaaS.
Developing from this, there is a "provisioning" function that, when other services are tied to the main user, automatically creates and sets up accounts for those services as well.
Provisioning functions are provided by all IDaaS services, whether the need is great or not.
The SSO service is not cheap, and the functionality is simple for the effort involved, so it is difficult to see the benefits of implementing a service that is worth the price. If you are going to introduce SSO, I thought it would be more beneficial to consider provisioning as well.
Impressions, etc.
After all, the key is the user ID and password used to log in to the PC or to log in to Office365, so it is most reasonable and easy to allow SSO in the main Active Directory.
Connecting external IDaaS to internal Active Direcotry requires setting up a server to run a relay application, and having access to Active Directory IDs and passwords is not very pleasant, and frankly, it's a hassle and I'd rather not do it if possible It's not very pleasant, and I don't want to do it if possible.
If Active Directory were to provide SSO services, independent IDaaS would lose business, but from a user's point of view, I thought it was inevitable.
As a countermeasure, the independent IDaaS side is also proposing a reverse provisioning approach, using IDaaS users as keys to create Active Directory and Office365 accounts for SSO, Well, normally, you would have Active Directory users first....
The provisioning function is a feature that we would like to use if available, but since the provisioning destination is an external service, we will not know how well the linkage will work until we actually use it.
The service to be provisioned also needs to be supported, so which IDaaS to be aware of then, starting with those with the most users....
Considering all of the above, my impression was that IDaaS will be consolidated into Azure Active Directory (ADFS).
However, as mentioned above, Azure Active Directory is still not as functional as independent IDaaS, and it is better to actually try it out to see if it can really do what you want.
