in ,

The Beer Drinker’s Guide to SAML, Hacker News

The Beer Drinker’s Guide to SAML, Hacker News

Product & Engineering


In SAML lingo, what happened? Let’s start by defining some terms:

      Identity Provider (IdP) – The software tool or service (often visualized by a login page and / or dashboard) that performs the authentication; checking usernames and passwords, verifying account status, invoking two-factor, etc. This was the Wristband Tent.

        Service Provider (SP) – The web application where user is trying to gain access. This was the Beer Tent.

          SAML Assertion – A message asserting a user’s identity and often other attributes, sent over HTTP via browser redirects. This was the wristband itself.

      Step 1 Explained: Beer Drinker Bob Goes to the Wristband Tent, and Software User Stu Goes to the Company Dashboard

      This step is where authentication by the IdP happens.

      For Bob, authentication entailed the Wristband Tent checking to make sure he was who he said he was (his face matched the picture on his ID) and making sure he met the requirements (he was of drinking age).

      For Software User Stu, authentication entailed checking his username and password, making sure his account was active, and invoking two-factor authentication to make sure he actually was who he said he was.

      This is a good time to explain that it’s best to think of the IdP as a role in the SAML authentication workflow, relative to the SP. The IdP is simply an authority that the SP trusts. What specifically the IdP does to verify a user isn’t of concern to the SP. The SP only cares if its one-and-only IdP approves of the user and issues a SAML assertion.

      What the Wristband Tent does to verify a drinker’s identity before giving out a wristband is of no concern to the Beer Tent – they only care if the drinker has a wristband or not. The Wristband Tent could require each drinker present a driver’s license, passport, proof of residency, turn their clothes inside out, then do pushups.

      It could even require they visit another tent – maybe a Necklace Tent – then return to the Wristband Tent wearing a necklace to get a wristband. The Beer Tent has no idea about any of this, nor does it care. The only concern of the Beer Tent is whether or not a drinker arrives with a wristband.

      Again, what the IdP does to verify a user’s identity is of no concern to the SP, Salesforce. Typically, IdPs ask for a user’s credentials, but they can also ask for certificates, invoke two-factor authentication, require the user be on a particular network – and, you guessed it, they can even redirect the user somewhere else to have the user pass yet even more tests. What an IdP does to verify a user’s identity is configured by the user’s company and can be influenced (or limited) by capabilities of the IdP solution itself.

      Thinking of the IdP as a role can be helpful for understanding that many products on the market today fulfill the role of IdP. Duo Access Gateway, Microsoft AD FS, Okta, OneLogin, Ping, Centrify and Shibboleth all serve the role of the IdP, to name a few.

      After the user is successfully authenticated, many IdP products then display a dashboard with tiles or icons of all the SPs available for that user to click on and be logged into. In our example, Stu clicked the Salesforce icon, which told his IdP to generate a SAML assertion for Salesforce that adheres to all of Salesforce’s requirements: what attributes need to be included in that assertion, and how it should be formatted for Stu to successfully gain access to Salesforce.

      Step 2 Explained: Bob Goes to the Beer Tent and Stu Goes to Salesforce

      This step is where verification of the SAML Assertion by the SP happens.

      For Bob, verification entailed the Beer Tent checking to make sure his wristband was legitimate and issued by the Wristband Tent they trust.

      For Stu, verification entailed Salesforce checking the SAML assertion to make sure it came from the IdP that Salesforce trusts. In addition to checking the authenticity and validity of the SAML assertion, Salesforce also looks in the SAML assertion to see who Stu is and who he should be logged into Salesforce as.

      There are often many SPs configured to a single IdP. So while Stu went to Salesforce this time, maybe next time he’ll go to Gmail and his company dashboard (IdP) will generate a different SAML assertion that adheres to Gmail’s requirements. This is like having many different tents – a Wine Tent, a Liquor Tent, and our favorite Beer Tent – all who trust a single Wristband Tent. The Wristband Tent can issue a different wristband for each of the wine, liquor or beer tents depending on where the drinker wants to go.

      IdP-Initiated vs SP-Initiated

      IdP-initiated versus SP-initiated refers to where the authentication workflow starts. It’s often asked about because some service providers support SP-initiated logins while others don’t. What’s unique about the SP-initiated login is a SAML request .

      An IdP-initiated login starts with the user

      first navigating to the IdP (typically a login page or dashboard), and then going to the SP with a

      SAML assertion . This is like first going to the Wristband Tent, then going to the Beer Tent after having received a wristband. The examples above where a user is logging into Salesforce and getting beer were both IdP-initiated.

      An SP-initiated login starts with the user first navigating to the SP , getting redirected to the IdP with a SAML request , then redirected back to the SP with a

      SAML assertion Beer Drinker Bob demonstrates SAML with Beer as a Service analogy This is like first going to the Beer Tent, getting sent over to the Wristband Tent because you don’t have a wristband, then returning to the Beer Tent when you do have a wristband.

      Why does this matter, and what does it mean? What is a SAML Request? It matters because these redirects (go to the Wristband Tent, then come back to the Beer Tent) require that the SP issue a SAML request. A SAML request says, “This user is trying to log in, but they don’t have a SAML assertion yet. Please help them get a SAML assertion, then send them back here. ”

      However, not all SPs can issue SAML requests, which limits logging into that SP only as IdP-initiated. (And seriously, SPs, if this is you it’s time to join the party.) A SAML request is like someone going to the Beer Tent without a wristband, the Beer Tent writing a note saying, “This guy wants beer. Give him a wristband and send him back, ”pinning the note to his shirt and shoving him toward the Wristband Tent. It makes it easier for people who like to drink beer, and that’s why we prefer it.

      Beer Drinker Bob Goes to the Wristband Tent, and Software User Stu Goes to the Company Dashboard

      Configuring SAML

      We’ve covered the basics of what SAML is, how logging in with SAML works, and a few of the most common SAML scenarios. Now, let’s talk configuration specifics: setting up the tents.

      Configuration for SAML must be done in two places: at the IdP and at the SP.

      The IdP needs to be configured so it knows where and how to send users when they want to log in to a specific SP. This is like setting up the Wristband Tent and making sure its workers know they’re checking IDs so that people can be served beer (and that they shouldn’t let minors have a wristband), and after they issue a wristband to point people toward the Beer Tent (rather than, say, a T-shirt Tent or out of the concert venue).

      The SP needs to be configured so it knows it can trust SAML assertions signed by the IdP. This is like setting up the Beer Tent and making sure its workers know to look for wristbands that match the wristbands that their trusted Wristband Tent are issuing (as opposed to a friendship bracelet someone just happens to be wearing).

      Beer Drinker Bob demonstrates SAML with Beer as a Service analogy IdP Configuration

      Specifications for a SAML assertion – what it should contain and how it should be formatted – are provided by the SP and set at the IdP. This is like the Beer Tent dictating what they expect to be on a wristband and the Wristband Tent being made aware of those expectations.

      The following values ​​must be set at the IdP for each SP, and there’s often quite a few of them. This is like a Beer Tent, a Whiskey Tent and a Wine Tent all trusting the same Wristband Tent. Often, IdP products can set these automatically behind the scenes, but as an admin you’ll need to provide at least


      of this information:

      EntityID – A globally unique name for the SP. Formats vary, but it’s it’s common to see this value formatted as a URL.


      Assertion Consumer Service (ACS) – The URL location where the SAML assertion is sent.


      Beer Example: “Arrive at the left side of the Beer Tent. That’s where the line starts. ” ACS Validator – A security measure in the form of a regular expression (regex) that ensures the SAML assertion is sent to the correct ACS. This only comes into play during SP-proposed logins where the SAML request contains an ACS location, so this ACS validator would ensure that the SAML request-provided ACS location is legitimate.

        (Example: SP-initiated login ^ https: // // beertent .com / saml / consume / $

        1. Beer Example: “Make sure you’re going to this Beer Tent and not some other tent.”

      Attributes – The number. of and format of attributes can vary greatly. There’s usually at least one attribute, the nameID, which is typically the username of the user trying to log in.

          Real Examples: NameID Format NameID Attribute

              Beer Examples: “The wristband shows your name is Bob Boozer.” “The wristband shows that was your first name and your last name.”

                RelayState – Not required. . Deep linking for SAML. This tells the SP where to take the user once they’ve successfully logged in.

              • Beer Example: “After the Beer Tent approves of your wristband, ask for a lager.”

              SAML Signature Algorithm SHA-1 or SHA – 384. Less commonly SHA – or SHA – . This algorithm is used in conjunction with the X. 512 certificate mentioned below.

                (Example: SHA –
              Beer Example: “The wristband has a hologram, so you know it’s real.” SP Configuration

              The reverse of the section above, this section speaks to information provided by the IdP and set at the SP. This would be the information we provide to the Beer Tent to give them a way to validate that the wristbands drinkers arrive with were truly issued by the Wristband Tent they trust.

              X. Certificate – A certificate provided by the IdP, used to verify the public key as passed by the IdP in the metadata of the SAML assertion. It allows the SP to verify the SAML assertion is

              actually coming from the IdP it trusts. SAML assertions are usually signed, however SAML requests can also be signed. Typically, it’s downloaded or copied from the IdP and configured by uploading or pasting it to the SP.

              Issuer URL – Unique identifier of the IdP. Formatted as a URL containing information about the IdP so the SP can validate that the SAML assertions it receives are issued from the correct IdP.


            How Is SAML Different From Oauth and Web Services Federation?

            We hear about these other SAML alternatives in passing, but how do they differ? Should you have an opinion on which one is best? Understand that SAML, OAuth, and Web Services Federation (WS-Fed) all vary technically, as well as how they’re best put to use.

                SAML – Most commonly used by businesses to allow their users to access services they pay for. Salesforce, Gmail, Box and Expensify are all examples of service providers an employee would gain access to after a SAML login. SAML asserts to the service provider who the user is; this is authentication.

                  WS-Fed – Web Services Federation It is used for the same purposes as SAML, to federate authentication from service providers to a common identity provider. It’s well supported with certain IdPs, like Microsoft Active Directory Federation Services (AD FS), but it’s not prevalent with cloud service providers. WS-Fed is arguably simpler than SAML for developers to implement, but its limited support among IdPs and SPs alike make it a tough sell.

                    OAuth – Most commonly used by consumer. apps and services so users don’t have to sign up for a new username and password. “Sign in with Google” and “Log in with Facebook” are examples of OAuth in the real world. OAuth delegates access to a person’s Google or Facebook account by a third party.

                      Typically the app the user is signing into can directly read information from the user’s profile or take actions (like post pictures or make updates) on their behalf; this is authorization. This would be like going to the Beer Tent and instead of the Beer Tent sending Bob to the Wristband Tent, they ask Bob to hand them his ID and sign off that the Beer Tent workers can go over to the Wristband Tent on his behalf and represent him; he is authorizing them.

                      What’s more important is to look at prevalence of each technology for each use case. SAML is ubiquitous in the workplace for cloud-based apps, while WS-Fed is not. Conversely, OAuth is ubiquitous among consumer apps.

                      Microsoft & AD FS Terminology

                      Microsoft’s Active Directory Federation Services has their own terminology and approach to SAML, so it warrants a short explanation. Microsoft AD FS is an identity provider. Think of it as Microsoft’s solution to the Wristband Tent: tricky to understand if you’re new to the world of Wristband Tents, but very customizable.

                        Relying Party is the term that Microsoft AD FS uses to mean Service Provider.

                        1. Claims Rules is another term that only. Microsoft AD FS uses. Claims Rules are just that: rules you can apply to alter how or when to invoke authentication. For example, an admin could set up a claims rule that only applies when a user comes to AD FS as they’re trying to get to Dropbox. Plus, it prevents them from using a mobile device, allowing that user to log in with a laptop or desktop device but not their Android or iPhone. Some IdPs other than AD FS can create similar rules, but AD FS allows for some of the most robust and complex rule creation.

                            ImmutableID is the Microsoft Azure AD equivalent. of an ObjectGUID. It’s not specific to AD FS, but it’s worth a mention.

                                WS-Fed is similar to SAML. and abides by many of the same rules. It’s a protocol specifically created by Microsoft and not widely supported by IdPs other than AD FS.

                              Troubleshooting Basics

                              The best way to troubleshoot SAML is the same way I recommend troubleshooting most issues: start with the basics.

                                  Scope – Is the issue affecting all users, or just a few? If no users can sign in, that’s an immediate indicator of a service interruption or misconfiguration. If you’re setting up an IdP and SP for the first time, it’s probably a misconfiguration.
                                  Experience – What is the user experiencing. that indicates an issue? Is the user getting an error on the IdP login page? Or is the user getting an error generated by the SP after they successfully authenticate to the IdP?

                                Because SAML “happens” via browser redirects, it’s usually pretty straightforward to determine where a problem is occurring – just look at the URL. If a problem is occurring while on a URL belonging to your IdP, well, it’s probably an IdP issue. Same goes if it’s the URL of your destination SP.

                                Beer Drinker Bob demonstrates SAML with Beer as a Service analogy Error at the IdP

                                For just a few users:

                                  Is there an error message? Does it give us any clues?

                                    Is the username and password valid?

                      Is the user account unlocked?

                    • Is the user successfully passing two-factor authentication or any other authentication steps?
                      1. Try again. Clear cache. Try in an incognito window. Try on a different machine. Is there a way to isolate and identify the issue?

                            What do the logs show?

                          1. For all users:

                              Is there an error message? Does it give us any clues?

                                Is the user able to resolve the URL of the IdP and actually view the login page?

                                  Is your IdP able to communicate with your identity store (like Active Directory)?
                          If configurable, keep the authentication flow simple and get one step working at a time, ie, work to make sure primary authentication is working successfully before moving on to troubleshoot two-factor authentication.

                        Error When Arriving to the SP Beer Drinker Bob demonstrates SAML with Beer as a Service analogy

                        For just a few users:

                          What is the error? Does it give us any clues?

                            Does the user have a valid username within the SP?

                            Check to make sure the username stored in the SP matches what is being passed in the SAML assertion. My favorite tool for this is SAML Tracer , which allows you to easily view the contents of a SAML assertion.

                                Does the user need to be in a specific group?

                                For all users:

                              What is the error? Does it give us any clues?

                                Are any users already provisioned within the SP?

                                What does the SP expect the SAML assertion to look like? What are the required attributes and their formats?

                                  Do all users need to be in a specific group?

                                  Now that we’ve talked about the ins and outs of SAML, there’s just one thing left to say: Cheers!


                            What do you think?

                            Leave a Reply

                            Your email address will not be published.

                            GIPHY App Key not set. Please check settings

                            Bomb squad called and two held after suspicious device found in car in Luton – Sky News,

                            Bomb squad called and two held after suspicious device found in car in Luton – Sky News,

                            SLIDE: In Defense of Smart Algorithms over Hardware Acceleration for Large-Scale Deep Learning Systems, Hacker News