SAML Glossary
Key definitions when referring to SAML.
SAML has its own jargon and acronyms. This page breaks it down and relates these terms to how you’ll hear them in the context of Foundry.
To learn more about SAML, see https://developers.onelogin.com/saml or one of the many other summaries on the internet. On this page, we focus on how these terms relate specifically with Foundry.
SAML Abbreviations and Terms
SSO – single sign-on. A user can sign on once, and then enter other connected systems like Foundry without having to log in multiple times, and without having to manage multiple usernames and passwords.
SLO – single log-out. In SLO, signing out of any one system can trigger a sign-out of all the other active sessions from the same SSO session. Foundry supports SLO.
IAM system – Identity and Access Management is “a framework of policies and technologies for ensuring that the proper people in an enterprise have the appropriate access to technology resources.” (Wikipedia). In the context of SSO, this refers to the partner’s overall infrastructure for managing user identities and the other applications in the ecosystem. Several popular IAM systems include PingFederate, Microsoft AD FS, Okta, OneLogin, and more.
IDP – identity provider. This is a principal component of the partner’s IAM and is the centerpiece of SAML SSO. In SAML, the IDP is like the hub of the overall authentication flow and holds the identities of the organization’s users. In Foundry, there is an administrative section where you set up your IDP in Foundry, that describes the key properties of your IDP.
SP – a service provider is a system like EVERFI that connects to an IDP to get a user’s identity. Think of SPs as the “spokes” in the hub (IDP) and spoke model. To implement SSO with Foundry, you’ll add Foundry to your IAM as a service provider that interacts with your identity provider. Depending on the nomenclature of your IAM, a service provider might be called an App (Okta, OneLogin, PingFederate), Relying Party Trust (AD FS), or other terms.
SP-initiated SSO – when a SSO is launched from the SP, typically by a user clicking a link on the SP website that requires login. In Foundry, this is the Customer Login Page.
IDP-initiated SSO – when a SSO is launched by the IDP, typically by a user being on a web portal on the IDP website, and having a link to a SP website like Foundry.
Technical SAML Terms
Here are some more detailed technical terms that probably won’t come up in everyday SSO conversations but it may if you get deeper with IT/security/integration people.
Certificate – In the SSO world, think of the Certificate as the Passport of an Identity Provider or Service Provider — it’s an official declaration of who you are as an organization. This is kind of like the SSL certificate that a website has. Foundry has a X.509 Certificate and you will likely need to reference it in your IAM setup. In the Foundry IDP Setup that describes your IDP, one of the key properties is your IDP’s certificate or certificate fingerprint (a digest of the whole certificate).
Signature – Just like you have a signature on your driver’s license, a SAML Response, Assertion and Metadata file also have a signature. It’s a way for the IDP and SP to verify they are who they say they are. Foundry signs its SAML Authorization and Logout requests.
Issuer (aka Entity ID) – In SAML communications the issuer refers to the organization that sends the SAML communication. The IDP Issuer will typically match up with the Entity ID in the IDP setup in the Foundry organization. Foundry’s Entity ID, for example, is: https://fifoundry.net/{org-slug}/saml/sp (where {org-slug} is your organization’s slug) or https://fifoundry.net/saml/sp (legacy mode).
Metadata file (or URL) – contains information about an IDP and SP, such as the Issuer, the URL endpoints of the SSO and SLO services, the certificate and signature.
Authorization Request (AuthnRequest) – in SP-initiated SSO, the SP (Foundry) sends an authorization request to the IDP requesting the user’s identity.
Response – whether a SSO is initiated by a SP or an IDP, ultimately the IDP will send to the SP a SAML Response containing the identity of the authenticated user (assuming the user authenticates successfully to the IDP) as well as other information. If you’re trying to troubleshoot something with SSO, you’ll need to find a SAML response.
Assertion – a section within a SAML response that contains user user id (NameID) and, optionally, other properties (Attributes) about a user.
NameID – the SAML property that identifies the authenticated user’s name. Probably the most important part of the entire SSO flow because this says who the user actually is. This is most commonly an email address, but it can also be an employee ID or any other unique property about a user.
Attribute – additional properties about a user that are contained in an assertion. This can vary from one implementation to the next. For example: first name, last name, email address, employee ID, etc.
ACS – Assertion Consumer Service, often called the Single Sign on Page. This is a URL for the single sign-on page.