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

Single sign-on and federated identify 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.


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

Authentication Service

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

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.

Trust Relationship

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.

Identity Provider

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

IDaaS Identities

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.

Image of a purple ad - Destination Certification