Federated SSO in CISSP Domain 5
Download FREE Audio Files of all the MindMaps
and a FREE Printable PDF of all the MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Transcript
Introduction
Hey, I’m Rob Witcher from Destination Certification, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics related to Single Sign-on and Federated Identity Management in Domain 5, to understand how they interrelate, and to guide your studies.
This is the second of two videos for domain 5. I have included links to the other MindMap videos in the description below. These MindMaps are one part of our complete CISSP MasterClass.
Single Sign-on / Federated Access
Single sign-on and federated identity management are both about allowing users to access multiple systems with a single set of credentials. User’s love this as they now only need to remember one terrible password instead of multiple terrible passwords, and they only need to authenticate once to magically get access to all their applications.
Single sign-on protocols and systems are designed to work within one organization.
Kerberos
A major protocol that enables single sign-on is Kerberos. Kerberos enables authentication via tickets over an insecure network.
Components
Kerberos is a complicated protocol that is very flexible, and as such has a lot of components
User / Client
The first component, or rather person, is the User or Client. This is the individual that would like to gain access to services through Kerberos
Key Distribution Center
Kerberos provides two services, the Authentication Service and the Ticket Granting Service, both of which are contained within what is known as the Key Distribution Center. The KDC.
Authentication Service
When a user attempts to access a service via Kerberos they first need to authenticate through the authentication service. The authentication service will check that the user exists and if so, will send the user two tickets, one of which is known as the Ticket Granting Ticket, the TGT.
Ticket Granting Ticket (TGT)
The Ticket Granting Ticket is then passed to the other component within the KDC, the Ticket Granting Service along with a couple of other messages from the client indicating what service the client wants to access.
Ticket Granting Service
The Ticket Granting Service will check that the service exists and if the user is authorized to access the service. If so, the TGS will create a Service Ticket and send it to the user.
Service Tickets
The Service Ticket is now finally what the user sends to the application in order to get access to the application. The user also caches this Service Ticket for any future access to the application while the ticket is valid and has not yet expired.
Symmetric encryption only
The final piece worth mentioning, related to Kerberos, is that by default it only supports symmetric key cryptography. This is a significant limitation as quite a few symmetric keys may need to be created and securely distributed amongst the components.
By the way, I’ve created a super detailed video explaining Kerberos which I’ll link to in the description below.
Symmetric & Asymmetric encryption
Sesame supports not just symmetric cryptography, but also Asymmetric- Solving the major symmetric key cryptography problems: scalability and key distribution.
Federated Identity Management (FIM) - Access systems across multiple entities
Now let’s talk about Federated Access. From a user’s perspective it looks exactly like single sign on. The user enters one set of credentials and they magically get access to a bunch of different applications. The key difference is that in Federated access users can gain access to not just internal applications, but also externally managed applications – think access to SaaS applications in the cloud.
Trust Relationship
Federated access relies on a trust relationship between 3 different entities: the user, the identity provider and the service provider. Essentially the service provider needs to trust the authentication that is being performed by the identity provider in order to authorize the user to access the service.
Principal / User
Let’s dig into these three entities: The first in the User, sometimes also referred to as the Principal.
Identity Provider
The identity provider is the entity that authenticates the user - Verifies the user’s identity via authentication by knowledge, ownership, or characteristic. In many organizations, the Identity Provider will be something like Active Directory.
Relying Party / Service Provider
The Service Provider, sometimes also referred to as the Relying Party is what the user wants to access. The service provider is often not an application owned by the organization, but rather an application owned and managed by a vendor. Again, think of SaaS applications that so many of us access through work nowadays for submitting helpdesk tickets, booking travel, entering expenses, etc.
SAML
There are a number of different protocols that enable Federated Access. The major one that you need to know about is SAML – the Security Assertion Markup Language
Tokens
As we talked about, Kerberos relies on sending tickets. SAML does the same thing, but doesn’t call them tickets, rather they are called tokens
Assertions written in XML
These tokens contain assertion statements - things like the user ID, Service ID, the timestamp and lifetime of the token. Assertions statements contained within a token are written in XML – the extensible Markup Language
Components
SAML was designed to be used for many different use cases, As such it is made up of a number of different components to make it flexible and adaptable.
Profiles
Profiles define how SAML can be used for different business use cases such as Web single sign on or through LDAP
Bindings
Bindings map SAML onto different communication protocols, for example HTTP, allowing SAML to communicate across different types of networks.
Protocol
The protocol component within SAML defines how entities send and respond to requests
Assertion
The assertion component defines the authentication, authorization and other such attributes.
WS-Federation
There are three more protocols that you should recognize as Federated Access protocols. WS-Federation, which provides both Authentication and Authorization capabilities
OpenID
OpenID which provides Authentication
OAuth
And OAuth which provides Authorization capabilities
And that is an overview of Single Sign-on and Federated access within Domain 5, covering the most critical concepts you need to know for the exam.
Have you checked out our CISSP Guidebook yet? You should. It’s awesome in my completely unbiased opinion as one of the authors!
We explain all these single sign-on and federated identity management protocols with super helpful diagrams.
You can see why our guidebook is awesome here at: destcert.com/CISSPguide/
If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.
I will provide links to the other MindMap videos in the description below.
Thanks very much for watching! And all the best in your studies!
