Choose Your Own SAML Adventure: A Self-Directed Journey to AWS Identity Federation Mastery

First Hour Exercise (Microsoft variant)

AWS supports identity federation using SAML (Security Assertion Markup Language) 2.0. Using SAML, you can configure your AWS accounts to integrate with your identity provider (IdP). Once configured, your federated users are authenticated and authorized by your organization's IdP, and then can use single sign-on (SSO) to access AWS.

In this workshop, you walk through an evolutionary set of steps that guide you through the setup and configuration of basic to increasingly more advanced SAML federation use cases. This journey starts with several required configurations that this exercise covers:

After you establish this minimum baseline, you can then select the advanced SAML use cases that appeal to you. You can progress through these additional use cases in any order you wish, focusing specifically on those which you find to be the most relevant for you and your organization. These advanced use cases include:

Finally, there are two versions of this workshop. This variant implements all of the above using a Microsoft stack, namely an Active Directory Federation Services 3.x IdP with an Active Directory backing identity store. The alternative variant implements all of the above using an open source software stack, namely the Shibboleth 3.x IdP with an OpenLDAP backing identity store. Each of these variants implements equivalent use cases, so we encourage you to use the technology set with which you are most comfortable with.


The following image provides a visual representation of what you are about to construct during this initial exercise.

Exercise architecture

Note: You should use this architecture and associated AWS CloudFormation template for demonstration and learning purposes ONLY. The template contains default passwords and has not been hardened in any way beyond the default configuration provided by the Amazon Machine Image (AMI). Furthermore, the IdP infrastructure has been simplified to focus on the learning objectives and is not set up for availability and scalability, and is not appropriate for production use.


The following list identifies the prerequisites for this workshop. If you have not assembled these elements, please the take time to do so now:

Getting Started

We have created a CloudFormation stack that automates many of the more trivial and time-consuming steps so that you can focus your time on the true learning objectives. However, there are several important things to note that you will use as you progress through the exercise:

You will have a chance to review the outcome of these configurations in subsequent steps.

Deploy CloudFormation Template

Start by logging in to the AWS Management Console, and select CloudFormation.

AWS Management Console

If you aren't already there, switch to the Tokyo (ap-northeast-1) region, and then choose Create Stack.

AWS CloudFormation Console

In the first step, Select Template, choose Specify an Amazon S3 template URL, paste the following URL, and then choose Next.

Select Template

On the second step, Specify Details, most of the parameters are already entered for you. Enter the remaining parameters according to the following table, and then choose Next.

Configuration Element Value
Stack name FederationWorkshopADFS
KeyName Select an existing EC2 key pair within the ap-northeast-1 region. If you do not have an existing key pair, see the documentation to create a new one.
PublicSubnetId Select an existing public subnet.
SourceCidrForRDP The CIDR notation for the IP range that RDP should be restricted to. The workshop facilitators will advise how to configure this best for the conference Wi-Fi. For static environments, can be used to determine your current IP address.
VPC Select the VPC that contains the public subnet above.
VPCCIDR CIDR Block for the VPC above (noted in parenthesis following VPC-id).

Specify Details

In the third step, Options, you may proceed with the defaults by choosing Next.

AWS CloudFormation Create Stack

Finally, review the information to ensure that it is correct, and then choose Create.

AWS CloudFormation Create Stack

The template requires 10-12 minutes to complete. You can choose Refresh during this time to view the creation status in real time.

AWS CloudFormation Create Stack

While you wait, start configuring federated access to the AWS CLI and SDKs

Later in this initial exercise, you will be implementing federated API/CLI access. This enables your users (in this case bob and alice) to access your AWS environment using their credentials through the AWS CLI or one of the AWS SDKs. While you wait for the CloudFormation stack above to complete, let's start this process by implementing the specific configurations and utilities that are needed for this capability. After the workshop, we recommend that you review this blog post for a more detailed review of the internal workings of the solution.

First, on your local workstation, if you do not already have one, you configure a minimal AWS credentials file.

Linux/OSX: ~/.aws/credentials
Windows:   C:\Users\USERNAME\.aws\credentials

Open this file using your favorite text editor and add the following contents, adjusted to your preferred region and output format. Then save and close the file.

output = json
region = us-west-2
aws_access_key_id =
aws_secret_access_key =

Note: An AWS access key pair is not configured in the above structure because the initial AWS STS call is authenticated by the SAML assertion returned by the trusted IdP. All subsequent API/CLI calls are authenticated by the key pair contained within the returned AWS STS token.

Next, you install three modules that fall outside the core Python distribution, specifically boto, beautifulsoup4, and requests. There are several ways to do this, but the pip utility, which is included in Python 2.7.9+, makes it a very easy task. Execute the following command to install the additional modules, as shown in the following screenshot.

pip install --upgrade boto beautifulsoup4 requests

pip install

Next, download a fully configured version of the script using a browser or your favorite command line tool.

curl -o

Script Download

This version is different from the one listed on the blog post in a few small ways.

You will execute this script later in this initial exercise, no further actions are needed at this point. If your CloudFormation stack has not yet completed, please read ahead through this guide to familiarize yourself with the content.

Review template outputs

After the stack creation has completed, use the Outputs tab to determine the public IP addresses of the Domain Controller (DC) and AD FS instances. Copy down these values as you will need them in the following steps.

AWS CloudFormation Create Stack

Next, navigate to the EC2 Instance dashboard to see the newly created DC and AD FS instances.

EC2 Dashboard

Wait for the green checkmarks under Status Checks before proceeding to the next step.

EC2 Instances

Configure users and groups in Active Directory

Now that you have successfully deployed the CloudFormation stack, you need to configure some users and groups in Active Directory.

Login to your Domain Controller via RDP

Login using RDP to your newly provisioned Domain Controller (DC) instance using the public IP address that you noted in the previous step. Use the Example\Administrator credential. See directions for how to use connect according to your client platform.

Login settings

Note: Recall that the password for Example\Administrator has been set to Pass@123.

To verify the RDP certificate, choose Continue as shown in the following screenshot.

Login settings

Configure Users/Groups in Active Directory

You are now ready to begin configuring the users and groups within Active Directory.

First, we need to create two user accounts, alice and bob. We have created a script to quickly create these two user accounts for you. Start by opening a new PowerShell window and executing the command sequence below, as shown in the following screenshot.

cd C:\cfn\scripts

Load Users

Note: This script also creates the service account adfssvc.

Next, we need to create a set of groups using a naming convention of AWS-<Account Number>-<Role Name>. The following section describes this naming convention. As you will see later on, the membership of these groups will control which users can access which accounts and roles within your AWS environment. To start creating the necessary groups, choose the Start Menu, type user, and choose Active Directory Users and Computers.

Open Active Directory Users and Computers

Expand, and then choose Users. Right click, choose New, and then choose Group as shown in the following screenshot.

New Group

Create a new group for the role ReadOnly using the naming convention above.

AWS-<Account Number>-ReadOnly

Be sure to substitute your actual AWS account number into the group name. If you need help finding your account number, see this documentation. Then choose OK to finish creating the group, as shown in the following screenshot.

New Group

Repeat the same process to create a second group for the PowerUser role.

AWS-<Account Number>-PowerUser

New Group

Understanding the AWS-<Account Number>-<Role Name> naming convention

In the preceding section, we utilized a naming convention of AWS-<Account Number>-<Role Name> for the groups stored in Active Directory. To understand why this was chosen, we must first consider several aspects of how AWS environments are commonly segregated:

The AWS-<Account Number>-<Role Name> naming convention was specifically formulated to provide a best practice pattern for group naming that was able to account for all the aspects identified above. While the specific set of dimensions an organization may choose to use for account segmentation or the specific set of named roles an organization may define will certainly vary from one organization to the next, this standard works in all known cases. We highly encourage you to use this pattern within your organization, as it has been proven across a large number of customer implementations at scale.

Add users as group members

Next, we need to add our two users, bob and alice, to our newly created groups. In this exercise, you perform this directly through the Active Directory management interface. This method is intended to provide the "cooking show" version of this process. In your organization, the process for a user to be placed into one of the groups used to control AWS access should be managed through an entitlement portal, a managed workflow environment, or other trusted process.

Important: In a federated scenario the IdP is entirely responsible for authorizing which roles within AWS a given user can assume. Using the patterns and configurations shown here, the groups in Active Directory serve as the source of truth for these entitlements. If a user belongs to one of the specially named groups, they can access AWS within the confines of the corresponding AWS account and IAM role. As such, please ensure that as you adapt these learnings to your environment:

Choose the AWS-<Account Number>-ReadOnly group you created above, and then choose the Members tab, and finally choose Add, as shown in the following screenshot

New Group Member

In the object names box, type alice;bob, and choose Check Names and then OK, as shown in the following screenshot.

New Group Member

You will see alice and bob reflected as group members, as shown in the following screenshot.

New Group Member

Repeat the same process for the AWS-<Account Number>-PowerUser group. However, this time only add alice as a group member.

New Group Member

Join AD FS to the domain

For our next step, we add the AD FS instance to the Active Directory domain served by the domain controller instance. This will allow the AD FS service that will be configured in subsequent steps to use the user and group information you configured above for authentication and coarse authorization purposes.

Login to your AD FS instance via RDP

Login using RDP to your ADFS instance using the public IP address that you noted in the above. Use the local Administrator credential, as shown in the following screenshot.

ADFS Public IP

Note: Recall that the password for the local Administrator account is set to Pass@123.

RDP connection

Update DNS configuration

First, we need to configure the AD FS instance to use the domain controller instance for DNS. Start by determining the private IP address of the domain controller (DC) instance. You can obtain the private IP address from the Output tab from the FederationWorkshopADFS CloudFormation stack you deployed above.


To update the DNS configuration, open a new Windows PowerShell window, and enter the following command.

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses <PrivateIPaddressofDC>

Note: Be sure to use the actual value of the private IP address of the domain controller in the above command.
Note: If you receive an error stating that the interface "Ethernet" does not exist, use a value of "Ethernet 2" in the above command.

Now test DNS resolution by pinging the domain controller using the following command.


You should receive replies from the private IP address of the domain controller instance, as shown in the following screenshot.

DNS configuration

Join the domain

To complete the domain-joining activity, enter the following command into the open Windows PowerShell window.


In the System Properties dialog, choose Change.

Computer Name

Under Member of, choose Domain, type, and choose OK.


In the Windows Security dialog, authenticate with a user name Administrator and password Pass@123.

Windows Security

You should see the message, "Welcome to the domain."


Close the System Properties dialog, and then choose Restart now to complete the domain-join process.

Note: From this step onwards, log in to the AD FS Server as Example\Administrator with a password of Pass@123.

Install and Configure Active Directory Federation Services

Now that you have joined the AD FS instance to the domain, you are ready to configure Active Directory Federation Services. Once your instance has finished rebooting, reconnect using RDP, paying attention to log in with the domain credential Example\Administrator instead of the local account.

Set the Kds Root Key

To avoid a benign message during the following AD FS setup, open a Windows PowerShell window and enter the following command

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)


Add Server Role

Open Server Manager, and choose Add Roles and Features

Server Manager

Accept the defaults for Before You Begin, Installation Type, and Server Selection by choosing Next three times.

Server Manager

On step four, Server Roles, choose Active Directory Federation Services, and choose Next.


Accept the defaults for Features and AD FS by choosing Next two times. Then choose Install.

Server Manager

When the installation is complete, choose Configure the federation service on this server.


Accept the defaults for Welcome and Connect to AD DS by choosing Next two times.


On step four, Specify Service Properties, choose import.

ADFS Configuration

Navigate to the C:\ directory, choose idp1cert, and then choose Open.

ADFS Configuration

Type Pass@123 in the password dialog for the certificate, and choose OK.

ADFS Configuration

Note: This certificate was created and signed using a fictitious certificate authority (CA). In practice, you would utilize a proper SSL certificate issued by the trusted CA of your choice. This simplification was done so that you can focus your time on the true learning objectives. Not appropriate for production use.

Type idp1 as the Federation Service Display Name, and choose Next.

ADFS Configuration

On the Specify Service Properties Account page, choose Select. In the object name box type adfssvc, which is the service account that was created earlier in the exercise. Then choose Check Names, and then OK.

ADFS Configuration

Type Pass@123 as the Password, and choose Next.


Accept the defaults for Specify Database and Review Options by choosing Next two times. On the Pre-requisite Checks page, choose Configure.


Choose Close on the Results page to complete the configuration wizard.


Configure AWS as a Trusted Relying Party

Next, we need to tell AD FS that it should offer authentication services for AWS. The SAML configuration for doing so is known as a relying party.

To start, choose the Start menu, type ad fs, and choose AD FS Management.


Choose Add Relying Party Trust to start the Add Relying Party Trust Wizard.


Choose Start to begin. Then, on Select Data Source, type the following URL for the AWS SAML metadata, and then choose Next.

AD FS Configuration

Note: SAML federations use metadata documents to maintain information about the public keys and certificates that each party utilizes. At run time, each member of the federation can then use this information to validate that the cryptographic elements of the distributed transactions come from the expected actors and haven't been tampered with. Since these metadata documents do not contain any sensitive cryptographic material, AWS publishes federation metadata at

Accept the defaults for Specify Display Name, Configure Multi-factor Authentication Now?, and Choose Issuance Authorization Rules by choosing Next three times. Choose Close on the Finish page to complete the Add Relying Party Trust Wizard.

AD FS Configuration

Configure claim rules for the AWS relying party

In a SAML federation, the IdP can pass various attributes about the user, the authentication method, or other points of context to the service provider (in this case AWS) in the form of SAML attributes. In order for SAML federation for AWS to function properly, several attributes are required. In AD FS, Claim Rules are used to assemble these required attributes using a combination of Active Directory lookups, simple transformations, and regular expression based custom rules. You will configure a total of four claim rules.

The Edit Claim Rules window should be already open, if not, you can re-open it from Relying Party Trusts, by choosing, and then choosing Edit Claim rules as shown in the following screenshot.


Choose Add Rule... to configure the first rule, and then choose Transform an incoming claim. Finally, choose Next.

ADFS Configuration

On the Configure Claim Rule page, type the following settings, and choose OK, as shown in the following screenshot.

Configuration Element Value
Claim rule name Name ID
Incoming claim type Windows account name
Outgoing claim type Name ID
Outgoing name ID format Persistent Identifier


Choose Add Rule to configure the second rule, and then choose Send LDAP Attributes as Claims. Finally, choose Next.

ADFS Configuration

On the Configure Claim Rule page, type the following settings, and choose OK, as shown in the following screenshot.

Configuration Element Value
Claim rule name RoleSessionName
Attribute store Active Directory
LDAP Attribute SAM-Account-Name
Outgoing Claim Type


Choose Add Rule to configure the third rule, and then choose Send claims using a custom rule. Finally, choose Next.

ADFS Configuration

In the Claim rule name box, type Get AD Groups. In the Custom rule box, enter the following, and then choose OK.

c:[Type == "", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

This custom rule uses a script in the claim rule language that retrieves all the groups the authenticated user is a member of and places them into a temporary claim named http://temp/variable. Think of this as a variable you can access later.

Note: Ensure that there isn't any trailing whitespace, as this may cause unexpected results.


Choose Add Rule to configure the fourth and final rule. Then choose Send claims using a custom rule, and choose Next.

ADFS Configuration

In the Claim rule name box, type Roles. In the Custom rule box, enter the following, and then choose OK.

c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-([^d]{12})-(\w*)"] => issue(Type = "", Value = RegExReplace(c.Value, "AWS-([^d]{12})-(\w*)", "arn:aws:iam::$1:saml-provider/idp1,arn:aws:iam::$1:role/FederationWorkshop-$2"));

This custom rule uses regular expressions to transform each of the group memberships of the form AWS-<Account Number>-<Role Name> into in the IAM role ARN, IAM federation provider ARN form AWS expects. It does so by matching the first pattern match (\d{12}) to $1 and the second pattern match (\w*) to $2 for each entry in the temp variable.

This attribute makes better sense later in the exercise when you see it in action. For now, the key takeaway is that you are defining the resulting value for the AWS Role attribute in a dynamic way (by mapping group memberships) instead of a static way (by explicitly defining ARNs). This dynamic resolution allows the IdP configuration to scale to support virtually any number of AWS accounts and any number of IAM roles without further configuration.

Note: Ensure that there isn't any trailing whitespace, as this may cause unexpected results.

ADFS Configuration

Choose OK to complete the Edit Claim Rules wizard.

ADFS Configuration

Configure host file entry for AD FS on your local workstation

Note: You should perform this configuration on your local workstation, not the EC2 instance where AD FS was installed.

Since is only an illustrative domain, you will configure a local host file entry instead of configuring a DNS record for your identity provider. Choose the direction set below based on your workstation's operating system (Linux, Mac, or Windows).

Windows host file entry

Use Notepad or your favorite editor to add a host file entry for to the public IP address of the ADFS instance, as shown in the following screenshot.

notepad %windir%\system32\drivers\etc\hosts

Edit /etc/hosts

Linux/Mac host file entry

Use vim or your favorite editor to add a host file entry for to the public IP address of the ADFS instance you noted earlier in the exercise.

sudo vim /etc/hosts

Edit /etc/hosts

Test host file entry

After configuring the host file entry, make sure you can ping your AD FS instance, as shown in the following screenshot.


Edit /etc/hosts

Configure the IAM Identity Provider

Now that we have finished the installation and configuration of ADFS, we need to configure AWS to trust the authentication and authorization information it provides. During this process, you will provide AWS with the SAML metadata from your ADFS installation, which details all of the encryption and signing certificates that ADFS will use. This exchange provides the preestablished cryptographic trust needed for AWS to utilize the assertions generated by ADFS.

To start this process, we need to configure an IAM Identity Provider within the AWS console.

Download IdP metadata

Start by downloading the ADFS federation metadata from your newly configured IdP. This is the companion to the AWS federation metadata that you installed in the IdP itself.

cd $HOME/Desktop (or another temporary directory of your choice)
wget -O adfsmetadata.xml --no-check-certificate

Download ADFS metadata

Note: You can also use a web browser to download the metadata if curl is not available on your local workstation.

Create AWS IAM IdP

With the metadata downloaded, return to the AWS Management Console, navigate to IAM, and select Identity Providers from the left pane.

Note: Certain versions of Firefox produce errors during the creation of the Identity Provider, consider using Chrome if possible.

Select Identity Providers

Next, choose Create Provider.

Select Identity Providers

Enter the following values to configure the provider, and choose Next Step.

Provider Type SAML
Provider Name idp1
Metadata Document Browse to file downloaded in previous step.

Configure Identity Provider information

Verify the information is correct and then choose Create to create the identity provider.

Verify Identity Provider information

The banner at the top of the screen provides confirmation that your identity provider was successfully created.

Identity Provider confirmation

Create AWS IAM roles for IdP access

In our final step before initial testing, we need to create a set of IAM roles that correspond one to one to the directory groups we populated earlier in the exercise. These roles will be named such that their resulting ARNs will match the regular expression transformation we configured in AD FS earlier. Start by selecting Roles from the left pane and then choose Create New Role.

Create new IAM Role

In Step 1, set the Role Name to FederationWorkshop-ReadOnly.

Create new IAM Role

In Step 2, select Role for Identity Provider Access and then select Grant Web Single Sign-On (WebSSO) access to SAML Providers.

Create new IAM Role

In Step 2, set the SAML provider to idp1 using the drop-down list menu. This configuration defines the specific federation provider that provides authentication and authorization into the role.

Create new IAM Role

In Step 3, review the role trust policy (no changes required) and choose Next Step to continue.

Create new IAM Role

In Step 4, select the ReadOnlyAccess policy.

Note: The policy that you attach here specifically controls the AWS actions that the federated user is authorized to perform. In practice, you would attach a more meaningful and appropriate policy. The ReadOnlyAccess policy selected here has been chosen simply to facilitate this learning exercise.

Create new IAM Role

In Step 5, review all of the role information and then choose Create Role to complete the process.

Create new IAM Role

Finally, repeat the entire sequence of the preceding steps for a second role named FederationWorkshop-PowerUser. All other inputs remain the same. After creating this second role, type FederationWorkshop in the filter box on the IAM Roles page. You should see both of your newly created roles listed.

Inspect new IAM Roles

Test federated access to the AWS Management Console

You are now ready to test federated access to the AWS management console using your newly configured Identity Provider. To do so, open a new browser window, and open the SAML tracer add on. We'll use SAML tracer to inspect the contents of the SAML assertions as they flow from the IdP to AWS. This allows you to see the results of your configurations and understand the information that AWS is consuming from your identity provider. See the following screenshot for help enabling SAML tracer.

Enable SAML tracer

With SAML tracer enabled, switch back to the main browser window and enter the IdP initiated login URL for ADFS.

Because we configured ADFS with a self-signed certificate, you will be prompted to add a security exception.

Self signed certificate security exception

After adding the exception, AD FS will return the login page. Log in using alice's credentials.

Note: Recall that alice's password has been set to Pass@123.

ADFS login page

After successfully authenticating, you will then be redirected to the AWS role chooser page. This page is presented because alice was granted more than one role based on her group membership in Active Directory. Select the FederationWorkshop-PowerUser role and choose Sign In.

AWS SAML role chooser page

You are then signed in to the AWS Management Console and provisioned into the role you selected. The selected IAM role and the associated attached policies control the set of AWS actions that your federated user can perform.

AWS Management console via federated login

Before moving on, switch back to the SAML tracer window, and scroll upward until you find the entry for Choose that entry, and select the SAML tab in the lower pane. As you look through the assertion, look for the <saml2:AttributeStatement>. This will allow you to see how the configurations you applied above translate into the actual SAML attributes that are passed to AWS. See the following screenshot for reference.

SAML Assertion in SAML tracer

Configure federated access to the AWS CLI and SDKs

In the final step of this initial exercise, you need to complete the implementation and testing federated API/CLI access that you started earlier in the exercise. This will enable your users (in this case bob and alice) to access your AWS environment using their credentials through the AWS CLI or one of the AWS SDKs.

Return to the directory on your local workstation where you downloaded the script, and execute it using either alice or bob's credentials.

alice@Ubuntu64:/tmp$ ./
Password: **************** (Pass@123)

Please choose the role you would like to assume:
[ 0 ]:  arn:aws:iam::012345678987:role/FederationWorkshop-ReadOnly
[ 1 ]:  arn:aws:iam::012345678987:role/FederationWorkshop-PowerUser
Selection:  1

Your new access key pair has been stored in the AWS configuration file /home/alice/.aws/credentials under the saml profile.
Note that it will expire at 2016-10-16T17:16:20Z.
After this time, you may safely rerun this script to refresh your access key pair.
To use this credential, call the AWS CLI with the --profile option (e.g., aws --profile saml ec2 describe-instances).

Simple API example listing all S3 buckets:
[<Bucket: mybucket1>, <Bucket: mybucket2>, <Bucket: mybucket3>, <Bucket: mybucket4>, <Bucket: mybucket5>]

After you've done so, let's utilize the profile for a few additional CLI calls. First, let's retrieve the list of saml providers.

alice@Ubuntu64:/tmp$ aws --profile saml iam list-saml-providers
    "SAMLProviderList": [
                    "CreateDate": "2016-10-18T20:26:17Z", 
                    "ValidUntil": "2116-10-18T20:26:17Z", 
                      "Arn": "arn:aws:iam::012345678987:saml-provider/idp1"

Next, let's inspect the FederationWorkshop-ReadOnly using a CLI filter.

alice@Ubuntu64:/tmp$ aws --profile saml iam list-roles --query 'Roles[?RoleName==`FederationWorkshop-ReadOnly`]'
            "AssumeRolePolicyDocument": {
                "Version": "2012-10-17", 
                "Statement": [
                        "Action": "sts:AssumeRoleWithSAML", 
                    "Effect": "Allow", 
                        "Condition": {
                                "StringEquals": {
                                   "SAML:aud": ""
                        "Principal": {
                               "Federated": "arn:aws:iam::012345678987:saml-provider/idp1"
              "RoleId": "AROAJZN6LB2TJXXXXXXXX", 
            "CreateDate": "2016-10-18T20:51:27Z", 
            "RoleName": "FederationWorkshop-ReadOnly", 
            "Path": "/", 
            "Arn": "arn:aws:iam::012345678987:role/FederationWorkshop-ReadOnly"

Depending on the AWS resources available in your account, try to formulate one or two additional describe or list calls using the saml profile. The AWS CLI Command Reference can help you construct these calls.

Exercise complete

Congratulations! You've successfully completed the first half of the exercise and now have:

With this setup complete, you are now ready to advance your journey into the more advanced use cases. As described in the introduction, you may complete these advanced use cases in the order and combination that you choose. To continue, see a brief summary of each use case and get started with your own SAML adventure.