尽信书不如无书

qq70191

　　From the book 《Modern Authentication with Azure Active Directory for Web Applications》
SAML

　　The Security Assertion Markup Language, SAML for short, appeared on the scene mostly for handling this very problem. Its origin dates back to the early 2000s as a concerted effort of various industry players that wanted to establish an interoperable solution to the SSO problem. SAML 2.0 is the most widely adopted version, with some systems (especially those in academia) still on 1.1.>

　　Although both Azure Active Directory and Active Directory Federation Service (ADFS) (from version 2 onward) support SAML, the .NET Framework does not offer any>

　　In a nutshell, SAML sidesteps the shortcomings of domain-bound cookies by, you guessed it, adding an extra abstraction layer. Instead of>
　　SAML follows precisely the blueprint introduced in the claims-based>Roles

　　I am sure you noticed that the sample scenario I introduced earlier contained one entity playing the role of the>
　　In the terminology of claims-based>Artifacts

　　SAML is guilty of having introduced not one but two widely successful technologies: the protocol it defines and the specific token format that the protocol’s messages exchange. I say “guilty”>
　　In SAML parlance, tokens are called assertions. They follow the exact token semantic described in the preceding section: they are a vessel for the>　　The SAML acronym, together with the epoch in which it was conceived, probably already gave away that SAML assertions are based on XML. In fact, the entire specification defines everything in terms of XML. That leads to a very expressive, powerful format that can represent pretty much anything. However, all that expressivity comes with various drawbacks. The main one is that XML is very verbose, which leads to big tokens. Furthermore, in XML, the same document can be expressed in multiple equivalent representations, and that flexibility becomes a problem when you need to perform signatures, where two elements listed in a different order can break a signature verification. Those are the main reasons that you won’t encounter SAML assertions in modern protocols later in the book, apart from cases in which they are used to bridge existing solutions to new ones.

　　It is tempting for me to use the SAML token structure to start entering into the mechanics of how claims are defined, tokens are scoped, and signatures are applied, but, as I said, SAML is not at the core of the modern protocols that are the main focus of this book. Those explanations will have to wait until a bit later.

　　Another important artifact defined by SAML is the format of its metadata documents. You already encountered the>Messages

　　SAML defines lots of different messages that support various sign-in flows, from the one triggered by an unauthenticated request to an SP (similar to what’s described in the claims-identity section), to one in which the>　　The other interesting category of SAML messages, Single Logout, focuses on providing a mechanism to propagate a sign-out operation to all the applications participating in an SSO session. SAML defines many other messages for various other operations, which I won’t mention here.
Status
　　SAML has had an impressive ride from its first versions in the early 2000s. It’s still going strong in many of today’s SSO deployments in enterprises, government, and education. SAML is widely supported in SSO products, developer libraries (across platforms and languages), and cloud services. For many of those products, the SAML functionality is the centerpiece of their offering. As I mentioned, Active Directory itself (both ADFS from version 2 onward and Azure AD) supports it. On the software vendor side, many applications in active development today use SAML, including software as a service (SaaS) apps. The protocol is alive and well.

　　That said, if you are starting to develop a new solution, SAML might not be your best choice.>