Federated SSO in CISSP Domain 5
To Download the FREE PDF of MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Hey I’m Rob Witcher, in today’s video we will be walking through a MindMap for Single-Sign on and Federated access within Domain 5 – to highlight the major concepts and terms, and how they interrelate, to guide your studies and help you pass the CISSP exam.
This is the second of two videos for domain 5.
Single Sign-on / Federated Access
A major protocol that enables single sign-on is Kerberos. Kerberos enables authentication via tickets over an insecure network.
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
The Authentication Service issues Ticket Granting Tickets
Ticket Granting Ticket (TGT)
The Ticket Granting Ticket is then passed to the other component within the KDC, the Ticket Granting Service.
Ticket Granting Service
The Ticket Granting Service issues Service Tickets
The Service Ticket is now finally what the user sends to the server, the application, in order to get access
Symmetric encryption only
The final piece worth mentioning, related to Kerberos, is that by default it only supports symmetric key cryptography.
By the way, I’m working on a detailed video explaining Kerberos which I’ll link to in the description below when it’s done
There is a second protocol, that enables single sign on capabilities, that you should know just a tiny bit about. It is known as Sesame, as in open sesame.
Symmetric & Asymmetric encryption
Sesame supports not just symmetric cryptography, and but also Asymmetric- Solving the major symmetric key cryptography problems: scalability and key distribution.
Federated Access (Access systems across multiple entities)
Now let’s talk 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.
Federated access relies on a trust relationship between 3 different entities: the user, the identify provider and the service provider.
Principal / User
Let’s dig into these three entities: The first in the User, sometimes also referred to as the Principal.
The identity provider is the entity that authenticates the user - Verifies the user’s identity
Relying Party / Service Provider
The Service Provider, sometimes also referred to as the Relying Party is what the user wants to access
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
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, timestamp and lifetime of the token. Assertions statements contained within a token are written in XML – the extensible Markup Language
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 define how SAML can be used for different business use cases such as Web single signon or through LDAP
Bindings map SAML onto different communication protocols, for example HTTP, allowing SAML to communicate across different types of networks.
The protocol component within SAML defines how entities send and respond to requests
The assertion component defines the authentication, authorization and other such attributes.
There are three more protocols that you should recognize as Federated Access protocols. WS-Federation, which provides both Authentication and Authorization capabilities
OpenID which provides Authentication
And OAuth which provides Authorization capabilities
And the final piece in this mind map, somewhat related to single sign on, is Identity-as-a-Service. Essentially a cloud-based service used for cloud-based access management.
The only part of IDaaS that I’ll talk about here, are the different types of identities we can use with IDaaS. First, is a cloud identity which is an identity created and managed in the cloud
Synced Identities are two identities, one created and managed locally and a second identity in the cloud. The key here is that these two identities are synchronized. A change to one identity is automatically reflected in the other.
Linked identities are very similar. You have two identities, one in the cloud and one local. The difference, is that there is just some indication of a linkage between them, BUT changes to one are NOT automatically synchronized to the other linked identity.
And Federated identities. This is what we talked about in Federated Access. A user has one identity that allows them to gain access to both local and cloud based services via Federated Access.