In this lesson, we'll cover single sign-on.
Single sign-on, also known as SSO,
is an authentication process
that allows a user to access multiple applications
or websites by logging in only once
with a single set of credentials,
such as by using a username and password.
And this approach simplifies the user experience
and increases productivity by reducing the need for users
to remember multiple passwords
across various websites and applications.
So, how does this SSO work?
Well, single sign-on works based on a trusted relationship
that is established between an application
and identity provider, also known as an IdP.
The identity provider is a system
that creates, maintains, and manages identity information
for principals while providing authentication services
to relying applications
within a federation or distributed network.
Now, let's take a quick look
at the simplified step-by-step process used by SSO.
Most commonly, SSO is used inside of an enterprise network
and relies on the trusted relationship
between your active directory controller
and your various applications and websites
that are part of the organization's network.
First, the user logs into the primary identity provider,
such as your Windows domain controller,
who most commonly accepts their username and password
as their method for authentication
or the use of a username and password with a one-time code,
making them more similar
to multi-factor authentication systems.
Then the user attempts to access a secondary application
or website that is configured to use SSO
and has a trusted relationship
with the primary identity provider.
For example, if you are trying to access
your organization's internal SharePoint server,
it might not ask you to submit
for your username and password a second time
because you have already been authenticated
by the primary identity provider,
your Windows domain controller,
and therefore the secondary application or website,
in this case, the internal SharePoint server,
will send a request to the primary identity provider
to verify the user's identity,
and the primary identity provider will then respond back
with their assertion that the user is authenticated.
At this point, the secondary application or website
grants access to the user.
And in this case, you are now logged
into the SharePoint server
and can continue to perform your required work role
for the day.
There are several benefits to using single sign-on
including an improved user experience,
increase productivity,
reduce information technology support costs,
and enhance security.
First, we can create an improved user experience.
Since users will only need to remember
one set of credentials,
this can reduce their frustrations
of forgetting their username or passwords
for websites and applications that they don't commonly use.
Second, we have increased productivity.
Since users can save time
by not having to sign in each application separately,
they can get more work done and less time,
which increases their productivity on their job.
Third, we have the reduced
information technology support cost.
One of the largest and more time consuming requests
that most server desks receive
is to reset a user's password when they forgot.
Since SSO has less passwords that you need to memorize,
this creates fewer password reset requests,
so that the help desk workload can be significantly reduced.
Fourth, we have enhanced security.
It may seem counterintuitive at first,
but single sign-on can actually improve security
by encouraging the use of stronger passwords
since your users only have to remember a single password,
and this also helps to reduce the risk of password reuse.
Now, many of us already use single sign-on on a daily basis
without realizing it.
For example, if you tried to log into diontraining.com
and you use your Google account to do that,
you're actually using single sign-on in our federated system
where Google is authenticating you
and then you log into our website as well
since we have a trusted relationship
set up within their system.
Another example that is used in the corporate world
where a company might set up a SSO
for their internal applications.
An employee logs in once into their company credentials
and then has access to their email,
project measurement tool, and HR system
without needing to log into each one separately.
To enable and support single sign-on,
there are three commonly used protocols,
LDAP, OAuth, and SAML.
First, we have LDAP.
The Lightweight Directory Access Protocol, or LDAP,
is a protocol used to access
and maintain distributed directory information services
over a internet protocol network.
LDAP can be used to look up encryption certificates,
connected printers and other services on the network,
and provide a single sign-on capability
where one password for a user is shared
between many different services on the network.
Lightweight Directory Access Protocol, as the name implies,
is often used as a directory service
to essentially share the information infrastructure
for locating, managing, administering,
and organizing common items and network resources.
These resources can include volumes, folders,
files, printers, users, groups, devices,
and other objects in your enterprise network.
For example, an organization may use LDAP
to form a directory of its employees
that allows information about those users
to be stored in one place
and accessed by different applications,
including your contact list, address books,
and email clients.
The Lightweight Directory Access Protocol
is also used in authentication
and serves as a central repository for user information.
When a user attempts to log into a system,
the system can curate the LDAP directory
to check the entered username and password.
If the LDAP directory confirms the credentials,
the user is authenticated and granted access.
LDAP can also store other user information
that can be used for authorization,
such as what groups the user is a member of
or what roles that they have.
This allows systems to make decisions
about what resources or services
a user should have access to.
While LDAP can transmit data in plain text,
it also supports a secure version known as LDAPS,
which can support LDAP over SSL or StartTLS,
both of which encrypt the data
to provide secure transmission.
This is particularly important
when transmitting sensitive data, such as user credentials,
over a semi-trusted or untrusted network.
Now, second, we have OAuth.
Open Authorization, or Oauth, is an open standard
for token-based authentication and authorization
that allows an individual's account information
to be used by third party services
without exposing the user's password.
For example, when you log into a website,
like diontraning.com,
and it offers one or more options to log in
using another website or services credentials,
that is actually OAuth at work behind the scenes
to allow that login process to occur.
The OAuth protocol is commonly used
for authentication and authorization in RESTful APIs
since it is designed to allow secure sharing
of user profile information between sites.
Users create an account with identity provider
and then they can use this account
to log into another OAuth website
without sharing their password to that specific website.
When using the setup, a user can grant a client,
like an application or website authorization,
to access parts of their accounts,
like their name, email address, profile picture,
and other details.
The user account is hosted by one or more resource servers,
also known as API servers.
Authorization requests are processed
by an authorization server,
which can manage multiple resource servers.
The client application or service must be registered
with an authorization server and provide a redirect URL,
and receives an ID and a secret.
When the client requests authorization,
the user approves the request,
and depending on the flow type,
and then the client receives an access validation token
by the authorization server.
This token is presented to the resource server
to access the requested resource.
To transfer this claimed data over the network,
the OAuth protocol uses the JavaScript Object Notation,
or JSON-formatted Web Tokens, known as JWT,
which can be easily passed in a Base64 encoded string
in URLs and HTTP headers, and can be digitally signed
for authentication and integrity.
Third, we have SAML.
The Security Assertion Markup Language, or SAML,
is a standard for logging users into applications
based on their sessions in other contexts.
Now, this single sign-in log on standard
has significant advantages over logging in
using a username and password though.
When a user logs in using SAML,
rather than asking for a password,
the application redirects the user to identity provider
with a SAML request.
The identity provider then verifies the user's identity
and sends a response back to the application,
which in turns logs the user
into the application or website.
Now, SAML can be a little complex,
but what you really need to remember
is that it enables services
to be decoupled from the identity providers
and eliminates the need for services
to authenticate users directly.
Instead of the service provider
conducting the authentication,
the service provider just receives confirmation
from the identity provider
that the user has been authenticated into the given service.
So remember, single sign-on, also known as SSO,
allows a user to access multiple applications or websites
by logging in only once with a single set of credentials.
LDAP is a protocol used to access
and maintain distributed directory information services
over an IP network.
OAuth is an open standard
for token-based authentication and authorization.
SAML is a standard for logging users into application
based on their sessions in another context.
Single sign-on is a great technology
that increases usability
and increases the security of your authentication systems
by relying on a network of trusted identity partners
to help ensure that each use
is properly validated and authenticated.