Federation and Empire
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 122 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/40560 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Information securityView (database)Presentation of a groupCodeComputer fontMarkup languageFormal grammarCommunications protocolToken ringSoftware testingStandard deviationObservational studyConsistencyPairwise comparisonVacuumUbiquitous computingPoint cloudMaxima and minimaSystem administratorBoundary value problemSelf-organizationPhysical lawIdentity managementMobile appSingle sign-onScalabilityInformation privacyReplication (computing)Public domainKerberos <Kryptologie>AutomationControl flowInsertion lossPasswordInformationFirewall (computing)Programmable read-only memoryComponent-based software engineeringHeat transferKeyboard shortcutUser profileWeb browserDialectContext awarenessSmith chartForcing (mathematics)ChainTransport Layer SecuritySpecial unitary groupPhysical systemMassCommunications protocolComponent-based software engineeringClassical physicsIdentity managementPay televisionSingle-precision floating-point formatInformation securityField (computer science)Markup languageWeb applicationSingle sign-onSound effectMetropolitan area networkExpressionView (database)Shared memoryLatent heatMaterialization (paranormal)Presentation of a groupInternet service providerAdaptive behaviorSoftware developerStandard deviationMereologyPublic domainKerberos <Kryptologie>Order (biology)Musical ensembleBit rateCausalityComputer-assisted translationSymbol tableLevel (video gaming)FamilyPhysical lawSelf-organizationDirectory serviceNP-hardWindowWeightGame theoryFactory (trading post)Multiplication signPermanentSystem administratorTwin primeDifferent (Kate Ryan album)Focus (optics)Vulnerability (computing)Information privacyObservational studyAuthorizationForceCASE <Informatik>Well-formed formulaIdeal (ethics)BackupWritingNumberWave packetException handlingInternet forumConfiguration spaceOrbitWeb 2.0Open setCartesian coordinate systemNatural numberGreen's functionTouch typingSummierbarkeitDisk read-and-write headPhysicalismDataflowBuildingHeat transferFile formatSign (mathematics)Type theoryInstance (computer science)2 (number)Maxima and minimaComputer fontAreaBoundary value problemData structurePort scannerToken ringDiagramComplete metric spaceResultantINTEGRALIntegrated development environmentQuicksortReverse engineeringPoint (geometry)Attribute grammarInformationPoint cloudWeb pageSet (mathematics)Protein domainLecture/Conference
08:48
Attribute grammarIdentity managementInformationStandard deviationEncryptionDigital signalFirewall (computing)InternetworkingComputer networkBranch (computer science)Web browserKeyboard shortcutAuthenticationKerberos <Kryptologie>PasswordToken ringSoftware developerSystem administratorAnnulus (mathematics)Dynamic random-access memoryAdditionPoint cloudSoftware maintenanceDirectory serviceDistribution (mathematics)Information securityMechanism designAuthorizationPrincipal idealService (economics)Latent heatTerm (mathematics)Standard deviationAttribute grammarSelf-organizationStatement (computer science)Single sign-onImplementationSoftwareWeb applicationWeb browserLocal area networkOrder (biology)Descriptive statisticsKeyboard shortcutMappingDigitizingIdentity managementFlow separationPublic domainIntegrated development environmentBranch (computer science)Combinational logicProcess (computing)Internet service providerNumberAuthenticationInformation securityPasswordSoftware maintenanceSingle-precision floating-point formatCASE <Informatik>Profil (magazine)Kerberos <Kryptologie>Service (economics)Set (mathematics)LoginElectronic signatureEnterprise architectureSystem administratorSoftware developerPoint (geometry)Row (database)Type theoryMilitary baseCodeGame controllerForm (programming)Musical ensembleAddress spaceMechanism designView (database)Web 2.0Shared memoryCommunications protocolDependent and independent variablesInstance (computer science)Public key certificateFirewall (computing)InformationOffice suiteMultilaterationDirectory serviceRollenbasierte ZugriffskontrolleWater vaporContext awarenessSymbol tableForcing (mathematics)Cartesian coordinate systemFreeware2 (number)Social classNoise (electronics)MereologyData storage deviceDifferent (Kate Ryan album)Broadcasting (networking)Natural numberWave packetContent (media)Sign (mathematics)Element (mathematics)VotingBuildingTorusMultiplication signProduct (business)Series (mathematics)PermutationLine (geometry)Ferry CorstenCoefficient of determinationLocal ringAreaInheritance (object-oriented programming)Ring (mathematics)BitDialectService-oriented architectureSpeech synthesisDirection (geometry)FlagDampingFamilyEncryptionGame theoryComplete metric spacePrice indexDoubling the cubeMixed realityPhysical systemInternet forumComputer animation
17:36
Execution unitData modelService-oriented architectureStandard deviationIdentity managementFunction (mathematics)Information securityHill differential equationMathematical analysisSingle-precision floating-point formatSign (mathematics)Dependent and independent variablesInformation privacyWeb browserUser profileMarkup languageGoogolMobile appHTTP cookiePublic domainIdeal (ethics)Vector potentialEncryptionDefault (computer science)Vulnerability (computing)Open setInternet forumComputer fontScripting languageFormal grammarGeneric programmingConstraint (mathematics)Service (economics)ArchitectureComplex (psychology)Token ringConfiguration spaceFiber bundleDebuggerMessage passingLoginImplementationComputer-generated imageryHTTP cookieWeb browserDependent and independent variablesSolid geometryGoodness of fitData miningStandard deviationMusical ensembleWeb 2.0Forcing (mathematics)FamilyMultiplicationCartesian coordinate systemEvent horizonPublic domainKey (cryptography)Configuration spaceInformation securityOpen setDirectory serviceGradientTerm (mathematics)Sign (mathematics)ImplementationQueue (abstract data type)View (database)Matching (graph theory)Video gameDemosceneNatural numberCASE <Informatik>Symbol tableNeuroinformatikWeb applicationInternet service providerMonster groupDirection (geometry)Classical physicsToken ringPort scannerOrder (biology)DialectAdaptive behaviorTransport Layer SecurityWeb serviceDefault (computer science)SoftwarePlastikkarteSoftware testingSummierbarkeitPlug-in (computing)WindowBitWell-formed formulaProcedural programmingEndliche ModelltheorieSoftware frameworkPresentation of a groupVulnerability (computing)Open sourceAttribute grammarState of matterDifferent (Kate Ryan album)CausalityMiniDiscError messageFrequencyWeb pageMultiplication signObservational studyPrincipal idealInformation retrievalEnterprise architectureEmailPoynting vectorSpeech synthesisKeyboard shortcutElectronic signatureExploit (computer security)Point (geometry)Row (database)String (computer science)Zwei-Niveau-SystemGreen's functionTouch typingComputer architectureLatent heatLine (geometry)Arithmetic progressionWebsiteProduct (business)Revision controlElectronic mailing listVector potentialCentralizer and normalizerIdentity managementLoginLimit (category theory)Direct numerical simulationProtein domainScripting languageCombinational logicMereologyComplex (psychology)Level (video gaming)Set (mathematics)WordFlow separationElectronic program guideLeakType theoryClient (computing)Service (economics)Computer animation
26:24
Internet service providerService (economics)Uniqueness quantificationRandom numberTimestampMusical ensembleBoiling pointBinary fileProxy serverChainingDependent and independent variablesFuzzy logicHookingSuite (music)Java appletProcess (computing)Keyboard shortcutSoftware frameworkCodeSample (statistics)GoogolData miningUncertainty principleHTTP cookieSelf-organizationOpen setStandard deviationSharewareComputer configurationSimultaneous localization and mappingWechselseitige InformationIntegrated development environmentWebsiteAttribute grammarRevision controlPrisoner's dilemmaProxy serverProof theoryUniform resource locatorLipschitz-StetigkeitLatent heatProcess (computing)Limit (category theory)Direction (geometry)Row (database)Computer musicMusical ensembleVideo gameFamilyProfil (magazine)Symbol tableFormal languageComputer iconLine (geometry)CodeInformation and communications technologyDependent and independent variablesKey (cryptography)Type theoryCartesian coordinate systemHill differential equationParameter (computer programming)CodeStandard deviationTraffic reportingForm (programming)DialectRange (statistics)Software testingCuboidElectronic mailing listStress (mechanics)Service (economics)ResultantChaos (cosmogony)WritingImplementationTouch typingHTTP cookieInternet service providerData miningMereologyGodInformation securityAndroid (robot)ChainWeb syndicationMiniDiscNumberWiener filterSoftware frameworkSet (mathematics)Monster groupWebsiteSummierbarkeitArithmetic meanInformation privacyVisualization (computer graphics)Integrated development environmentInheritance (object-oriented programming)Game controllerMultiplication signSelf-organizationEuler anglesRing (mathematics)Different (Kate Ryan album)Open setMoving averageCommunications protocolSingle-precision floating-point formatGoogolTemplate (C++)Texture mappingFile formatHydraulic jumpSuite (music)Token ringGame theoryGoodness of fitKeyboard shortcutExtension (kinesiology)Intrusion detection systemMessage passingWeb applicationProjective planeWeb 2.0Identity managementLoginPort scannerSampling (statistics)AuthenticationTimestampReal numberHookingCodierung <Programmierung>Bit error rateWeightEvent horizonVulnerability (computing)Complete metric spacePresentation of a groupAutomationFlow separationError messageBinary fileAreaRandom number generationAdaptive behaviorJava appletDomain nameComputer animation
35:12
MathematicsOpen setExecution unitVulnerability (computing)HTTP cookieService (economics)Internet service providerPasswordOpen setProcess (computing)WebsiteLoginDirect numerical simulationIdentity managementMusical ensembleDirection (geometry)Lattice (order)Gastropod shellMiniDiscGoogolField (computer science)Mereology.NET FrameworkCartesian coordinate systemComputer-assisted translationLink (knot theory)Projective planeService-oriented architectureLevel (video gaming)Reading (process)State of matter
37:03
Open setCache (computing)WebsiteGoogolHTTP cookieSharewarePlastikkarteService (economics)Identity managementInternet service providerUser profileCommunications protocolStandard deviationMetadataLimit (category theory)PhishingComputer fontTopologyThomas KuhnExecution unitComputer networkPairwise comparisonInformation securitySurfaceInterface (computing)Integrated development environmentComputer wormSign (mathematics)RingnetzArchitectureEmpennageBinary fileState transition systemToken ringFormal verificationRegular graphProof theoryProgrammable read-only memoryPublic domainDefault (computer science)Control flowAttribute grammarAxiom of choiceTelephone number mappingProcess (computing)Form (programming)Software developerSample (statistics)CodeForm (programming)Cartesian coordinate systemField (computer science)Electronic signatureDefault (computer science)Point (geometry)Communications protocolGame controllerSystem administratorSingle sign-onOrganic computingSelf-organizationVulnerability (computing)Centralizer and normalizerMereologyImplementationProcess (computing)Internet service providerLine (geometry)Term (mathematics)Profil (magazine)Extension (kinesiology)Standard deviationService (economics)Web applicationIdentity managementVector potentialPhishingMetadataSoftware developerRingnetzInstance (computer science)Flow separationInformation securityPresentation of a groupSign (mathematics)Attribute grammarLatent heatProof theoryService-oriented architecturePublic domainCASE <Informatik>Level (video gaming)Set (mathematics)Directory serviceVideo gameInsertion lossGreatest elementDialectConfiguration spacePower (physics)Type theoryPort scannerMiniDiscRow (database)VoltmeterEmailAddress spaceReal numberDisk read-and-write headShape (magazine)Complex (psychology)Information and communications technologySession Initiation ProtocolSpecial unitary groupHydraulic jumpRing (mathematics)Stress (mechanics)Bit ratePerspective (visual)Elasticity (physics)Symbol tablePhysical lawLogic gateNichtlineares GleichungssystemEvent horizonSoftware testingData miningPrototypeMoore's lawMultiplication signRAIDComputer fontSeries (mathematics)Web 2.0CuboidExpert systemDirection (geometry)Computer fileSolitary confinementAreaStaff (military)Hill differential equationPhysicalismComputer animation
Transcript: English(auto-generated)
00:00
Hello everyone. Thanks for joining this talk, especially so early in the morning. My name is Emmanuel Bouillon and I'm going to discuss with you today some security issues that you might have to cope with when dealing with federated identity. And more precisely, I'm going to discuss a specific type of federated identity,
00:22
which is a symbol-based federated identity. So first, I'm an InfoSec guy, and more importantly, everything that I'm going to say today expresses only my own view, my own views, and especially do not involve any of my previous current and future employers. And everything is provided for educational purposes only.
00:46
Okay, so that being said, here is the outline of this presentation. It's made of six parts. First, an introduction, what is it about and why should we care. In the second part, I'm going to discuss what is the problem we are trying to solve
01:01
and how have we been doing it up to now. And then in the third part, I'm going to introduce some, not all, but some of the standards and specifications around the federated identity area. And I'm just going to give the minimum material so that everybody will have in mind what is needed to take the most of the rest of the
01:24
presentation. And the rest of the presentation is going to be made of two parts. One is how can we adapt classical web application scanner in order to have them to better cope with some of the protected web applications.
01:44
In this part, I'm going to illustrate the type of results that these kind of tools can provide. And in the last part, I'm going to present and to discuss some security considerations and issues that we need to have in mind prior considering joining or creating such a federation.
02:07
And finally, a conclusion. So let's get started. So SAML stands for Security Assession Markup Language. And this talk is about SAML token and claims-based identity and access management. So I'm going to take a radically low-level approach of this protocol.
02:23
That means I'm not going to discuss the API provided to developers in order to implement this kind of protocol. Maybe you're familiar with the Windows Identity Foundation API, which is the .NET API that allows developers to somehow
02:41
transparently integrate SAML protocols in their applications. So I'm not going to use this kind of level of approach. But I'm just going to look at the lowest level of those protocols. And also, this presentation is not about a consistent and formal study of every involved standard.
03:02
I'm just going to introduce two of them, but you'll see that's enough to get some interesting results. So basically, the approach I've been using is some sort of standard reverse engineering. Basically, find vulnerabilities and then go back into the specification and see why something got wrong.
03:25
So what are going to be the takeaways of this presentation? First, tools, adaptive tools in order to have classical web application scanners to better cope with SAML protected web applications. Then I'm going to demonstrate an assumption
03:43
which is that involved standards can be read as an attempt to circumvent the same origin policy. I'm going to show a demonstration about that. And finally, some important security considerations that you might have in mind before joining or creating such a federation.
04:02
So why should you care? The thing is that the protocol and specification I'm going to discuss in this presentation are getting more and more prevalent. Actually, many influential major industrial players are currently pursuing the development of SAML-based protocol to achieve federated management. And also, it's support of the federation that makes SAML
04:29
particularly suitable for cloud deployment. That's why it's getting ubiquitous. So whether you like it or not, it's coming your way. And the last point is that depending on the context of deployment, you're considering business to business, banking,
04:44
government for, let's say, tax payment, for instance. This kind of deployment and associated security issues might entail some very thorny contractual, legal, and even privacy issues. That's why it's important to take care of that.
05:02
So now, where do we come from? What is the main problem that this kind of standard tries to solve? Let's say that the single sign-on solution or issue within a single domain has been solved now for a while. So initial solution for this single sign-on
05:22
problem in a single domain were very efficient from an administrator point of view, but maybe not that satisfactory from a security point of view. Maybe some of you still have in mind the Sun Yellow Page solutions and the NIS system, for instance. So that was very interesting from an administrator point of view, but maybe not that
05:40
interesting from a security point of view. But today, this problem has been solved by more robust protocols like Kerberos, for instance. Kerberos is a protocol you use very commonly to solve a single sign-on issue within a single domain. Typically, that's what you're using if you're using Active Directory environment. The thing is that now we need to solve this single sign-on solution, but between
06:03
organizations, between different domains. And that's typically what SAML tries to solve. So the goal is to have a user and administrator-friendly cross-organization boundary single sign-on. So here I'm going to focus on the web applications. So that needs to be secure, scalable, easy to manage, and ideally taking care of
06:22
privacy and anonymity issues. So this problem is not new, and of course, previous solutions have already been deployed. Usually, these solutions rely either on duplicating user accounts, more or less intelligently, or by establishing trust
06:40
relationships between security domains, typically Kerberos trust relationships between Active Directory domains, be it unilateral or bidirectional trust relationships. And of course, these type of solutions come up with some drawbacks, and that's this kind of drawbacks that SAML tries to solve and to tackle.
07:05
And also, regarding the problem of privacy and anonymity, some previous standards have been defined but never really been deployed nor widely adopted. So what do we need to know about federated identity standards? So in this part, I'm just going to give a very, very high-level view of some of the
07:23
involved standards around federated identity. So here you have a diagram that shows the complete ecosystems of specification around federated identity. As you can see, they are quite numerous, and most of them are supported by an organization called OASIS, the OASIS Consortium, which OASIS stands for
07:44
Organization for the Advancement of Structured Information Standards. So I'm not going to discuss all of them, just to introduce two of them. So first, the SAML specification, which in fact, it's a set of specifications in itself. And secondly, the WS Federation specification,
08:04
which basically describes how to orchestrate flows in order to achieve this multi-domain single sign-on solution. So let's start with SAML. SAML stands for Security Assertion Markup Language, and basically it
08:23
consists of building stone components, which once put together allow a given number of use cases to be supported. And these components primarily allow the transfer of identity information, like authorization, attributes and so forth, between autonomous organizations that
08:45
have an established trust relationship. That's the primary goal of SAML. And there is also something you need to know if you start looking at this kind of specification and document. That's the fact that there are some terms which have a specific definition in this context, so it's better to know
09:04
their definition. So basically you have SAML assertions, SAML protocol, bindings and profile. So SAML assertions, I'm going to go back to that later, but typically it's a signed XML document which contains statements about a principal, a user for instance, that a given asserting party
09:26
claims to be true. SAML protocols are basically the description of request and response that are needed in order to obtain or to submit a SAML assertion. And SAML bindings are the mapping between SAML protocols and
09:43
other layers of transport protocols. Typically you have bindings for SAML and SOAP, you have the HTTP redirect binding and the HTTP post binding. And finally, you have what they call SAML profiles, which basically is a combination of assertions, protocol and bindings in order to support a
10:05
given number of use cases or federated scenarios. Within the standard there are several profiles defined, like the web browser SSO profile or the single log out profile. I'm just going to mention two of them during this talk. First, the web browser SSO profile because that's
10:23
really the most common use case, the most widely used use case regarding SAML specification. And the second one is identity provider discovery profile. I'm going to mention this one because actually it is prone to some security issue. So what are SAML
10:43
assertions? So as I said, a SAML assertion is a signed XML document containing claims or attributes about a user. And it's a set of claims contained in a SAML assertion that define the identity in regard to what we call the relying parties, that means let's say the web application. And what you need to have in mind also is that
11:04
these claims do not need to be distinctive for this user. It doesn't have to be a login name for instance or something like that. It can just be a statement like yes, this user has paid his monthly fee for the public library or yes, this user is over 21. So here
11:20
is how it looks like. So with no surprise, it's a signed XML document which follows the XML data signature standard. So you get information regarding the issuer, regarding the signature, how it has been computed, et cetera. You get information about the subject and more interestingly, you get information
11:46
about the attributes contained within the SAML assertion. And typically in the enterprise use case, these attributes are obtained from an enterprise directory that can be a group
12:00
membership, yes, this user has this role in my organization or yes, this user has this address in my organization. And as you can see above, there is also some specific attributes that can be of interest like the audience attribute. So the audience attribute is basically the statement that says for which relying party this SAML assertion has been made
12:23
of. So that's interesting because that allows to prevent some SAML reuse attack. But for this to be effective, it needs to be taken into account by the relying party side of the implementation. And as we'll see later, it's not always the case. Some implementation do not verify that and that's obviously a security issue. So how is SAML used? SAML is
12:44
standard based, so widely supported and supposedly interoperable between implementations. And the underlying standards include XML encryption, XML digital signatures and X509 certificates. It heavily relies on HTTP for conveying the SAML assertion through the
13:06
firewall. There are several types of deployment. It can be deployed in a local network. It doesn't have to be in a federated environment. It supports branch offices deployment. It allows remote users to access the corporate
13:22
network. But also and more importantly, it supports federation and the federated scenario. And I'm going to discuss that more into detail later. And so basically the idea is to have a nice, neat, cross domain single
13:40
standard solution so that our beloved users are happy with their experience. So how does it work? Here I'm going to focus on the web browser profile. Basically it's a four-step process. First you have your user who requests access to the web application and at this
14:05
request do not contain any SAML assertion. The web application is going to redirect the web browser to the user's identity provider using the HTTP record 302. And at this point the user's identity provider is
14:22
going to authenticate the user one way or another. We don't have to know the type of authentication that is going to be used at that point. It can be providing a login password or just using the corporate single sign-on solution, typically Kerberos based. So once the identity provider has authenticated the user, then the identity provider is going to build
14:44
a claim with appropriate attributes inside and sign it and send it back to the user's browser with an HTTP post form with an auto submit request to the web application. So that's how it's going to be transparently, this SAML assertion is going to be
15:01
transparently sent back to the web application. And as this web application is claims aware, it's going to grant access to this user according to what is inside the claim, the SAML assertion. And that's how you achieve the single sign-on solution. So our users are happy with that. And that's really interesting from an administrator and developer
15:22
point of view. Because in fact, from the web application side, you don't have to know and to deal with what kind of authentication mechanism has been used. So the corporate environment can completely change the way the user is authenticated. The code of the web application still remains the same. That's what
15:42
makes it really interesting from a developer point of view. So now you could say, so what? Because indeed, okay, we have a single sign-on solution for web applications, but actually, there are other ways to achieve that. Typically, you can use a Spinego over a GSS API with
16:00
either Kerberos or NTLM as a security underlying party. So you could say, okay, why bother about that? So the main, actually, the main idea for that is that it supports federation, that is the sharing of identity between domains, what they call in the specifications, a multi-domain SSO issue. It also
16:20
supports delegation, that's the maintenance of identity to backend services. And also, it provides an enhanced access control, which we call a role-based access control. It provides a finer granularity regarding how you can provide access control to your web application. And so that's it
16:43
for SAML. So the second standard I wanted to introduce here is the WS Federation standard. So WS Federation is an approved OASI specification that defines mechanism to allow different security to federate. So what does it mean? Basically, access to resources managed in one
17:02
realm can be provided to users or principles whose identities and attributes are managed in other realms. So that's how you guarantee the fact that users' management stays on the side of their own authoritative domain. You don't have to bother about users' management of the
17:21
other domain. So that's why it's really interesting. And also, it includes mechanism for brokering of identity attribute and authentication between realms. And in this document, in this specification, the last chapter is about security considerations. So it's a very small chapter, it's one page. And the last
17:42
bullet of this chapter is about compromised services. And I'm mentioning it here because I'm going to get back to that later and see how this kind of consideration might really be an issue depending on the type of deployment you're considering. So here is basically how it works. So it's a very
18:00
simple use case. So it starts by having your web browser or your client connected to a web application. As you don't provide any claim to this web application, it's going to redirect you to its own identity provider. At that point, the target domain identity provider is going to redirect the browser
18:21
to the user's identity provider. At that point, the user's identity provider is going to authenticate one way or another the user. And if once authenticated, the identity provider is going to retrieve some attribute, typically from an enterprise directory, build a claim, sign it, and send it back
18:42
to the browser using a post redirect to be sent back to the identity provider of the web application. And at that point, the identity provider of the web application is going to, of course, verify the signature and also possibly change, remove any attributes within the claim, sign it back
19:01
and send it back to the web browser with a post redirect to the web application. At that point, the web application, which is going to receive this signed claim, this claim is signed by its own identity provider, so it's going to be trusted. And according to attributes contained in this claim, it's going to grant access to its resources. So that's
19:22
basically how this multidimensional sign-on solution at a very high level is achieved. And just to be complete, just be aware that they are, okay, I've just introduced a very simplest use case, but they are more complex architecture
19:42
supported by the standard and the specification, and typically what they call the procured federations model, which basically is when you have a centralized identity provider which is trusted by many others. And also, please be aware that users can have several identity
20:02
provider depending on its context, and that's in some sort, the user can have several identity and doesn't only have to trust one identity provider. So that's it about the introduction of the standards. Just to be complete, I've just added a list of what I
20:23
consider as important previous security study on that domain. So some security issue has already been discovered in SAML, so either regarding SAML standards themselves or regarding some of their SAML implementations. So now that's
20:41
where things are getting interesting. When you look at the, within the complete documentation, there is one document called SAML technical overview. So it's still a draft, but basically that's the document where they explain all the rational behind SAML. And what is really interesting at that
21:01
point is that the really main driver, and that's how it is written in the document, the main driver for SAML is the limitations of browser cookies. And it's written like that, typically browser cookies are never transmitted over DNS domain, and basically when you read that, you have the things that they consider that's quite sad.
21:20
And SAML solves this problem. So of course, the multi-domain signal solution is relevant and a legitimate issue to be solved, but on the other hand, if browser cookies do not fly between DNS domains, there are good reasons for that, and basically it's part of the same policy. So from a
21:43
security point of view, what I mean here is that we could read that as, okay, SOAP sucks, let's build a workaround. So from a security point of view, there are these kind of considerations of rational, has a great potential for security issues. So the question is, is it a fail or not?
22:01
Typically, can a bad guy steal cookies? I'm going to provide the response later, so you need to be patient. To conclude with this part, just a few words regarding implementation security. So typically for implementations I've been looking at, like ADFS, Shibboleth, or simple SAML PHP,
22:21
there are some good aspects, like the fact that by default, tokens are encrypted, and by default also replay attacks are properly addressed. So you might also meet some problem regarding the compliance with the standards, like the fact that unsigned logout request gets accepted,
22:43
or the fact that the target is not verified. And finally, you also have some implementations which have some vulnerability, and I'm going to demonstrate two of them, an open redirection vulnerability and a cookie leak or a cookie theft within one
23:02
implementation. So before that, I'm just going to explain how to adapt our classical web application scanners in order to have them to properly cope with SAML protected web applications. So, regarding our tool set, I think
23:22
that these considerations have already been mentioned this morning by the presentation of related to SOAP and how to adapt web application scanners to better cope with, to better assess web service based on SOAP. So, but typically web application
23:42
scanner tool set is made of several kind, a combination of different tools chosen by a more or less objective criteria. So typically it can be made of professional or community edition of commercial tools like WebInspect, Acunetix and others. You can use
24:01
free and open source software for web application scanning, Skipfish, Nikto, and some typically some Firefox plugins also. And also, very often when you discuss with people doing that for a living, they very often use their own homemade custom scripts that they have been developing
24:20
throughout their years of experience. Regarding methodology, it's a little bit of the same. Supposedly, some more or less formal procedures are supposed to be followed. You can rely on some generally accepted best practices like the OWASP testing guide or the OSSTMM framework. But finally,
24:41
it always heavily relies on habits and personal preferences, and also still many manual adopt and improvise steps are needed. So that's why I think we still need to adapt our tool set. Even though if some great presentation regarding how to do web
25:01
application assessment states that we should not be a tool, the only tool which is needed is our brain, I do think that properly using the right tool often makes a difference, especially because usually it's a time-constraint exercise. And regarding SAML, there are two reasons to adapt our tool sets. The fact that it allows a traditional
25:22
assessment of web application scanner to cope with SAML tokens, to cope with SAML protected web applications. And also, these kind of applications and their security, they often rely on very complex configuration settings. So this configuration
25:42
are prone to error, and we need tools to assess that the good configuration settings are effectively in place. So the thing is that there are already some existing tools that can help the web application scanner, the web application pen tester when they have to cope with SAML. So I've
26:01
listed some of them here, at least all those I know of. So you've got the UniNet SAML tracer, which allows you to see decoded SAML token that your brother is receiving and sending. You have the SAML debugger, the FIDO SAML debugger, it's an online application that
26:22
allows you to submit a token, either encoded or decoded, and then you receive the answer, which is either decoded or encoded. And the last one is a really interesting one. It's provided by part of their initiative called Federation Lab. Basically it's an online
26:43
automated check of service provider implementation. So if you have a SAML implementation of the service provider side, you can trust the Federated Lab, STS, and then online ask a scan of your implementation, and then you're
27:02
able to see how compliant is your implementation regarding the standard. So I'm going to show you the result of this kind of scan just later. And of course you can always use a manual approach to encode and decode a SAML token. So here you can see an example of a report from a Federation Lab
27:23
service provider tester. So I've just installed an out-of-the-box Hello World application using a single sample PHP, which is one implementation of SAML standards. So the good news is that you have many success, so that means somehow some compliances with the protocol, but you also get some errors
27:41
regarding these compliancies, like the fact that indeed single logout, unsigned single logout requests are accepted, and that the targeted audience attribute is not checked by the service provider side, which is in fact a security issue. So, we still need to adapt our toolset,
28:00
and there is one area where this adaptation is proved to be very, very useful. It's when encoding and decoding a SAML token. And again, this encoding and decoding touches several parts of the assessment of the efficiency of the web application scanner. First, having access to, in clear
28:21
to this SAML token, or having access to SAML token decoded allows you to really more accurately understand the meaning of all these requests and what these tokens are made for, what are the attributes involved, for which they are imparted. That helps
28:40
understanding what is going on. Also, it allows you to do some more relevant request mangling, and if your web application scanner happens to be a fuzzer, then you instead of fuzzing a big chunk of meaningless data, you're going to fuzz properly and more accurately each specific parameters. And
29:00
also, it allows you to swap some anti-replacive guards, like the fact that you need to change random numbers at each different request, and it allows you also to update timestamp on the fly, which then allows you to have longer scans to unfold properly, which avoids some false negative results.
29:23
So, here is the approach I've been using. So, it's not a new approach, because typically it has already been used by people from JDS security when they have been assessing the Microsoft proprietary binary encoding of sub-request for WCF. So, the idea is to chain proxies. So,
29:42
first you have a pre-processing proxy, whose role is to decode the request and encode responses. The middle proxy is actually your real scanner when you have, when you do your real, let's say, assessment, and when your intelligence as a pen tester takes
30:02
place. And then you have the post-processing proxy, which encodes the request back and decodes the response back. So, this way, the application still receives the request in the proper expected format, so it can work properly. So, to implement
30:21
that, I've been using BERT pursuit, so I guess most of you know this web assessment tool. It has a very, very good cost benefit ratio. And what is really interesting with this tool is that it provides a Java API to extend BERT suite functionalities, and it's particularly suitable for pre-
30:41
and post-processing. And also there exists some bindings both for Python and Ruby. So, I've been using the Ruby framework to extend BERT suite, which is called BUBY. Recently, a very complete tutorial has been presented and is available on the net. And for this kind of
31:01
tool, you only need to hook either event proxy message or event HTTP message. So, the proof of concept I've been developing is freely available at this URL, and you can use and test it basically to retrieve all the results that I'm going to present now. So, I'm not going to discuss the code itself.
31:20
Just going to show you how it looks like. So, here is a pre-processing proxy, which received the initial request. So, as you can see, or maybe you can just guess that you see a non-coded token. So, very difficult to understand. And this pre-processing proxy is going to edit this request and decode
31:42
the token. So, now you have the complete decoded token, which is sent to your middle proxy, which is actually your real web application scanner. So, typically, if you're using burp as a middle proxy, then you can send this request
32:00
to burp intruder, for instance, to have specific parameters to be mongled with. And at that point, the middle proxy is going to send this request like that and to the post-processing proxy, which will receive the decoded token in clear, if you want, and then
32:22
the post-processing proxy is going to encode the sample token back to its appropriate format. So, that is going to be sent to the application as it expects to be sent. So, that's basically how it works. So, I'm just going to illustrate some results you can obtain using this approach.
32:42
So, I've chosen two results to illustrate these tools. And I've chosen these two because actually these results and these vulnerabilities are more standard related related to standards and specifications themselves than related to implementation. So, that was
33:02
more interesting and more fun to discuss these two vulnerabilities. So, the first one is an open redirection. So, an open redirection is just the fact that you can craft a request so that the target is going to respond with a redirection to another site which is controlled by the
33:22
attacker. So, it's not critical and as you are going to see, it's somehow built-in in the sample standards. And then I'm going to illustrate how this can lead to a cookie theft. That means that we are going to be able to make cookies fly between the DNS domains using these
33:40
kind of vulnerabilities. So basically, if you visit this site, a bad guy can inconspicuously discover your identity provider. That means, what is your originating organization? So, that's at least a privacy issue. So, to demonstrate that, I've been leveraging
34:02
an existing live open to everyone test environment which is provided by the Norwegian Academic Federation. It's called OpenIDP. And I've been using Adobe account. And the cookie I'm going to steal actually is https.openidp.fider.no.
34:21
So, what you're going to see is a complete four-step sample authentication. Right? And then, you'll see how a bad guy can just steal this cookie. So, it's a three steps process. First, the victim accesses the bad guy site. This site contains a craft
34:41
get request to the service provider which will actually leverage OpenIDP to get back, to send back the cookie to its own controlled website. So, to make it more visual, this relation will not happen, will not go to the bad guy website, but I've crafted
35:01
a Google search request using, as an argument, the cookie. So that you can see that indeed the cookie is appended to the Google search request. So, let's see. So, at the beginning, you're going to see that this is the only just the open
35:21
redirection vulnerability. So, I don't know if you see anything, but basically, here you see that it's a get request that goes to openidp.fighter.no and when you click on this link, you're going to be automatically redirected either to Google or to DefCon website.
35:44
So, that's a Google redirection. You have the same thing with this request goes to OpenIDP and gets redirected to DefCon. So, that's just the open redirection vulnerability. So, nothing very critical. But then, let's imagine that your user is connecting to a service provider that
36:01
chooses a SAML and OpenIDP as its identity provider. So, here, this is the relying party which is called veryopenid.net I choose my identity provider. Then, automatically, I get redirected to my identity provider. I need to authenticate. So,
36:21
here, by using a login password. And then, you'll see that this is going to craft a SAML request and send back to the application so that I get authenticated. So, that's the four-step process you know I've been describing. And now, if you click on the malicious link, you'll see
36:41
that the redirection ends up with the theft of the cookie. So, that's the demonstration. I hope that's clear. So, that's how you can steal a cookie and make cookie flies between DNS using this kind of vulnerability.
37:02
So, the thing is that actually if you go back to the standard these vulnerability are not implementation issue but more specification issue because it comes from the identity provider discovery service profile and actually it's built-in. The open redirection, when you look at the standard, it's written like
37:21
that. The open redirection is in the specification. And actually, when they wrote this specification, they somehow felt that there was a kind of issue. This is a quotation of the standard. This protocol had the potential for creating additional opportunity for phishing. So, at least they were aware that it was dangerous. And they
37:40
proposed a workaround based on service provider metadata but it's only should workaround and there's no way they don't explain how we could exchange metadata between the service provider and the discovery service. So, basically the developer have just implemented properly the standard and they get So, that's what I wanted to show you about this part.
38:01
And the last part is about consideration regarding the design of deployment and trust topologies. So, as you remember, this is the simplest use case of Federation scenario. So, you have two
38:21
organizations with a trust relationship. But, of course, there are more complex there are more complex deployment scenarios. So, the question is does it really does this kind of deployment really implement new risks? It's a contentious issue but
38:41
basically, other solutions are not that more secure. So, that's to be simple. We can say about that. So, here is a very simple deployment scenario. You have one organization which tries to access another organization application and the access control is based for instance on the
39:00
user's email address. So, typically, what happens in real life is you have several domain organization B as several customers accessing its application. So, now the question is what if one of the organization gets either malicious or compromised? Typically, what if organization C signs a claim
39:20
for a user of organization B? The thing is by default if you installed everything by default, this is going to work. That means that your application is going to grant access regarding the attribute in the claim because from a signature point of view, everything is fine. So, you need to implement yourself all the business checks at that point that will prevent this kind of
39:44
attack to be working. You need to do that. That's not implemented by default. But at least in this simple scenario, you can do it. You still can do it. The thing is there are more complex scenarios and more realistic scenarios where it's getting more complicated typically when you have
40:01
an indirect trust relationship where you have a central trust worker that conveys trust between organization. So, at that point, so here is how it works. You've got one organization which tries organization D which then is trusted by organization B. And then you have this single sign-on solution that works perfectly fine the same way flowing between these three organizations. Now the question
40:21
is what if organization C signs a claim for a user which is not part of its own organization? Let's say what if organization C gets either my issues are compromised? The thing is in this case, if organization D does not do its job by checking everything that needs to be checked and which is not done
40:41
by default, then organization B has no way to see the trick and to see that things got wrong. So, if the STSD signs a token then STSD has no way as an organization, organization B has no way to see that something went wrong. So, that
41:02
means that in fact organization B fully relies on organization D to properly check some claims. But so that means then what is the policy for that? Do we have a way to verify is auditing permitted etcetera? And how to prove other parties compliance with relevant requirement? So that's typically the questions that are usually unasked and even less answered. So, the bottom line
41:21
is what about malicious or compromised ADP in a federation? And can a malicious ADP impersonate another domain's users? That's really the main, the bottom line issue. And is there any safeguards in place? I mean business said to prevent that. And who own this safeguard? Do you as an organization
41:41
own this safeguard? Or do you regard due to the fact that it's a trust, an indirect trust of topology do you delegate this kind of safeguards? So, that's in fact because when you look at implementation by default these safeguards are not implemented. And if you get back to the standards themselves actually this kind of consideration
42:01
has just been cursorily mentioned in the in the bullet I mentioned previously which is a compromised services. And indeed they recognize that this is really a very major issue when you have this third party broker trust relationship. But on the other hand, in practice it works by default.
42:21
And there are no proposed solutions on how to prevent that. So in the case of a third party broker trust, you need to control the loss of controls. That means who's ability is involved, et cetera. What are other parties' obligations? And that's the concern I've called Samuel claims laundering.
42:41
So all relies all relies on the checks made at each level. This must be done since default settings are permissive. So typically, ways to do that is to have key attributes which are kept added to avoid the turning situation into a blind trust to this organization part.
43:01
And the thing is also when you join a federation usually you don't have access to this policy. You don't know exactly what checks are in place. And that's an issue. So that ends up this presentation. So the main takeaways
43:21
of this presentation are first knowledge and tools to keep on properly assessing some protective web application. How to adapt the tool sets classical web application to cope with some protective web application. Then proven assumption that the fact that standards
43:42
can be read as an attempt to circumvent the same policy. So you've got the tools and process to go there. And also important security design configuration. The thing is without taking care in security by design is possible. And typically when you have a cross-domain
44:02
trust relationship with Active Directory for instance if one domain gets compromised, this domain cannot impersonate other domains users. Whereas with a SAML indirect trust implementation it's possible by default. So you need to take care of that. With SAML-based
44:22
cross-domain by default this kind of situation will occur. Of course this approach applies to other forms of delegation of a federation. Field developers and marketers are ahead of security guys. Yet default security things are not
44:40
secure. So the make it working approach might lead to insecure deployment. And that's why we need to keep up with this kind of protocol to avoid big deployment security failure and post-mortemly discover that there has been an issue. So we need to get acquainted with
45:02
the involved protocols to properly assess the design and the deployment of such a federation. And also adapt our toolset because probably bad guys will. And very probably also that would be helpful to have better guidance or improved standards on how to
45:22
protect to avoid this kind of issue because today it really relies on diligent administrators and developers to implement these checks. But if we had a common way to solve this kind of issue then even in terms of assessing it could be far more easier.
45:41
I guess that's all I have for today. So I'd like also to thank one of my great colleagues for his great help and extensive knowledge on SAML. And if you have any questions I can try answering them now or I will be in room 2 Q&A.
46:00
Thanks a lot for your attention.