Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

SAML2 IdP Overview 1.0

Revision as of 14:47, 17 December 2007 by Markus.sabadello.gmail.com (Talk | contribs) (Flow #1: First time log in)

The Higgins SAML2 IdP supports the SP-initiated SSO profile defined by SAML 2.0 specifications. Two parties are involved in this profile: A service provider (relying party, SP), and an identity provider (IdP).

The SP offers protected services and relies on the IdP to authenticate users.

Deployment Scenario

In this document, the base URI of the SP is:

http://localhost/org.eclipse.higgins.saml2idp.test/

The base URI of the IdP is:

http://localhost/org.eclipse.higgins.saml2idp.server/

In the screenshots provided in this document, the relying party is indicated by a light blue screen border and the identity provider by an orange screen border.

Protocol Flow

The following diagram is taken from the SAML Technical Overview and outlines the protocol flow in the SP-initiated SSO profile (see http://www.oasis-open.org/committees/security/).

Saml2idp-1.png

The remaining part of this document describes the protocol flow in greater detail and illustrates the roles played by Higgins components. If the user is not logged in at the IdP yet, all 7 steps are executed (this is referred to as Flow #1 in the rest of the document). If the user is already logged in at the IdP, steps 3 and 4 are omitted (this is referred to as Flow #2 in the rest of the document). 

Flow #1: First time log in

In this situation, the user tries to access the SP for the first time. The following welcome screen appears:

File:Saml2idp-2.png

Figure 1: Start screen of the service provider.

In order to access the secured applications or pages at the SP, the user initiates some kind of action; in this case, a button is clicked. The SP then sends a SAML2 AuthnRequest message to the IdP using the SAML2 HTTP Redirect binding, i.e. by including the message in a deflated, base64-encoded form as a URI query string parameter. The SP also optionally includes a SAML2 RelayState, i.e. string data it needs to use after the SAML2 protocol flow is complete (e.g. the original URL the user was trying to access). Depending on the SP's configuration, the SAML2 AuthnRequest may be digitally signed.

The SAML2 endpoint URI of the IdP is a configurable setting at the SP.

Example SAML2 AuthnRequest message sent from the SP to the IdP:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
	AssertionConsumerServiceURL="http://localhost/org.eclipse.higgins.saml2idp.test/SAMLEndpoint"
	Destination="http://localhost/org.eclipse.higgins.saml2idp.server/SAMLEndpoint"
	ID="ccocfkmlnocbajegpiheahonbcambbapiibggije"
	IssueInstant="2007-12-17T18:40:52.203Z"
	ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect"
	ProviderName="Test SAML2 SP" Version="2.0"
	xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
	xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<Issuer>Test SAML2 SP</Issuer>
	<NameIDPolicy AllowCreate="true"
		Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
	<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod
				Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" />
			<SignatureMethod
				Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
			<Reference URI="">
				<Transforms>
					<Transform
						Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
				</Transforms>
				<DigestMethod
					Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
				<DigestValue>N1Aze93QqDxax3cmBgPmKFNdM8U=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>
			KjfZwX9RkNrr3Epo/yRfDiFhqBeJCO5lFe/Ni/leBvBH8FRCT3p+2w==
		</SignatureValue>
		<KeyInfo>
			<KeyValue>
				<DSAKeyValue>
					<P>
						vzIPsacspz2XUcXP0hmWx2u56y9t/nTZRKGyFcVi1K/bao0C+0KjvXKkAPNhBb9TzYsCZbtZNH3a
						OSVvsw1XVYHCeneHAircY/oJ0BqfBBg4gQe1H/CPXwixI+zjBSF5pMOBq4etcsH+SD/JYj1NsRwn
						/2yQccUjUKeapbHn8TVNwVRYwg5QZL9AQ4b/pGoqO+df3kIqUL7lVyW+l6XprtVQU9jen47c4KQ1
						sodHHPwgoXmT27hLAedC0cu4UUYFjwgbEoS1UBUoNajmGFNFeMpEtj1j4cHRoiZIxwYgEqzanp2f
						Lgq7LlMa07vIuZBk6jyrw77Mza7TqxFNoVO89w==
					</P>
					<Q>j/ukaZe37ncVwe4c/+GQex1Kqic=</Q>
					<G>
						fu8RMe0ijgLi4Pw/KY57HdIBjmBge4XG1fX8IoT2wxv4QFO+FmijCqCcOiWk3osVyJIjqGJyH4kq
						RwvSZl6pd8FAdP1HfZDMwBP9ML6NpE5WAe+MP+b3ydoUqI25JqCS2H9DypUIHxqN+NaLTDm67O9m
						tTSckEMbXiARccwgnEgyNCFFulmm8vh8L6iT+56pesCyykMp6PDDo8AI2U9SR5EzUAQe5Yl39fCp
						lb7H+tbOBclal00OUXezRGNh5c6JlM5J6YpY/gll2D0nv3VtubVOlc104LIpvFzphF7x5hv5HvI+
						jUemrFIx0I8C3lv+8Xndwe8YwszLRrxvNe0jPQ==
					</G>
					<Y>
						vM9EhHB8cKakhExdDZ/1pnWFeZOBKgC/c1/OoY1wGh4yAz5zDkkZPg/dXpEOkWuz241WXipcUbym
						L+lZXcT+bTs8CQdIkw738vopoJfT0r75fKd85lT1pRH/nQ4i82J+vHrqOrfFc5CryxxqCRkZP4DW
						B5t62LBoIMMsrdsMVKpzCJmUgnnIY8B4maJe2BYVRBBhISGoBnTKSWxObUg30fIfRlVFFxtTeWq8
						tPS9u+MI3HuFn0MPVL+TgBw24ufSWPEEUiZU0eDdjzF51/yTVqUCHYNJH7gG7kugrQ8LdKes7rfD
						c9glkilm1iAcSCfNvqsktKcN+BCOaCdsQhT5yw==
					</Y>
				</DSAKeyValue>
			</KeyValue>
		</KeyInfo>
	</Signature>
</samlp:AuthnRequest>

This AuthRequest message is encoded and sent to the following URL at the IdP via HTTP Redirect: http://localhost/org.eclipse.higgins.saml2idp.server/SAMLEndpoint?SAMLRequest=nVbbkqrIEn33KzqcR6LlIigathOCInhBRPD2hkUBhUABxUX9%2BkF7957eM3NOnDlvVRmZK1fmqsis0e%2B3OHqrYE4QTj7abIdpv8EEYBcl%2FkfbtpR3sf37uDUiThylw0lZBIkJsxKS4m1CCMyLJkzGCSljmO9gXiEAbXP10Q6KIh3SdISBEwWYFDTO%2FQ4EEUoJ7ATI91FCOk9QDrlpp2jw6N1kvZolbopRUrTfpo0JJU7xovXv0BpaTUF%2FwdOmH20AMPCucZRgcHFC6KcogE6Akwtw4svFSRG6NFAhbLwJKaGWkMJJio82xzD9d5Z7Z%2FsWKw55ZihwHY7pnttvRo4LDHAkoeSzY2WeDLFDEBkmTgxJpwDDJ48h12GGl08nMlQty3g3oYtyCIoXSIVcmOtNxEfbevb2GcO97Yz22%2F5LGu4pTSNWQv6WZfg9i%2FMlyw%2Fv4Uu6%2Fx6T%2FijjK%2BTWPIGfXa%2FrulN3O03L6aYRLM3wdOPVePzWHo92yG9EKnP4Re0fgxiaGTyDXIL8ryjoaomHxyPZSXCCGmHR46X2GhYBdt8mkY9zVATxP0Fa5icVcya%2FN7DvgOWT96eF6bLCb4cmTMZxDJOCtOlvHP8X6L%2BydYnzTgKHfQKZ0IN5Uzh8s03to90UYuVOQjycx%2BTb%2Bd8lgEkFI5xC95188Xzmor9DT5HfvIr%2Fh%2F4X9U%2BEvROVcKyzkwccdLfZ9ObcuiCWfCNeKrq7Fu2PEf3dc0T%2FLLk5f1ftZ08%2FHZehd66PA%2FOq53l3lmL6bnpTpASZBBfyRogUSOuIjqBUSaqomLLVTSmu%2Fvj4BP0GNFrC%2B2eG5vDDNN1N%2FrwY4%2BqhGcQBJH1wRxscDSaIDzeuFHr3QUEn1tlczu8K2CN2SV8czMgUswyr4%2FI6MfRAugysx4nI50tx1tWu09rs9hWp2eP%2BpMowgeoE5eBE4wUjZZ4k%2Bby%2FhaxKy8axRjeNeoTSThHS9UbKeFgAolK7Kb04haxOzDpp0dx9C4Ad2kvopBc1Ea29Xu%2FNU%2B0L2%2FNqMNnyFzqd42xDuV73qmX2qh%2Ft7wcq6h3TvNhv7UEIE74P%2BOWWbRHsqqpR%2B%2FgYW1w%2FWE2gKzOg5G37pIS1f5nhHWtLNtadMJ4rugLX6awI2ZAHqonRWbvVJ3%2BWPZwk5bzWys%2F6q2jtMP1KK8%2FStRfe87rfXz%2BcvpXdFB3vN%2BLgpYcxHm3HIV1enTPs9hOwryEPaGq%2BhTd2mSHQuGzHo%2FnYK0VzDRkU%2BivEGzW9PAl91dWksHlOkD%2FOWe8oatji6lvFb5UNpcQolDMZbNDh2sVkf19oYTZf3FX%2BmrXMutqdo17qisrENVjVO0%2FXtWQM1quens6EwwRSa4O6dO8utjONExaZvOPUwfSe2pp6y3RKd1bWNO71N4O4VVg7cJ2tL0c0MQGo%2FWTm33VZUcoojsUqEFc9ZFFCL4VEvt%2Bv67RnTKdYnGicPdiZwuxhT7ZQOEXdgSenrejSV6nispFA5EQMs7GP8GHO9UAAvUW0Fha9U3qi%2FSjipkxSdfdFedlvIsAy%2FEpLK%2BWRBkr%2FJgSVoFYa1QptGOeKdmM0Ue5GFSUeE7eG4qkmj5WZ3yodMqGxfaowH49O42o9mAWqJIKlcw1mN3d6ptk0OSjwvJGWvkwDlt7gE1vPA%2F4%2BeQiP6fV6NnzaPaazzfVQPjiePRxRCuzLPW6tqOh8BBZ1sYgob13tWve7YoVTvPAsJu8L3tIVhchiU1Olky2PRG5BVWqebXJPAYKc32%2B3TDabBPz00JKEosetJKyt1yR3yXq%2FTB%2FyIrb9JNFOosTHzgJy0mlvSlKg7eZYSqzl7nDbXGy%2Fy3iaZ0Z7RbkVFjxkYqswdoOSWmtdtVQSZm3sV5TlSzXHl97uYMxmNjrbDJy64UMRWPpu7TNbVk%2F6Qu378%2F619POtuHKXkPRzb9oCAz%2B6oihm0QTsZE%2BvMnItlkCnJHnjyC7ZBpZwfz30UzPRfpks9K%2FHzyn053waj16fgnz8y4Ie0T%2Bso%2Bf21qYGjhC4NzM6wrWcQ6doNnqRl82XQmlGuVP85z3MdtiXBbnv3st1WCYkhQB5CLqvjfD3P9j4Dw%3D%3D&RelayState=Test+relay+state%21%21 The AuthnRequest message is read by the IdP. In particular, the AssertionConsumerServiceURL attribute is needed to pass the SAML2 protocol response back to the SP. The IdP keeps the SAML2 RelayState string to pass it back to the SP later. The IdP checks if the user is already logged in by examining the session state. In this case, the user is not logged in, so the IdP needs to ask the user to provide authentication materials (credentials). The kind of credentials required and the backend store they are validated against are configurable at the Higgins SAML2 IdP. This authentication mechanism is handled by the Higgins IdAS (Identity Attribute Service) component, which can authenticate users against a wide variety of underlying technologies. In this case, an LDAP directory is used, therefore the IdP asks the user to provide a username and a password.

Saml2idp-3.png

Figure 2: The Higgins SAML2 IdP asks the user to provide credentials.

If the user enters invalid credentials, an error message is displayed.

Saml2idp-4.png

Figure 3: Invalid credentials entered at the IdP.

Once the user enters valid credentials, the IdP assembles a SAML2 Response message and sends it to the SP using the SAML2 HTTP POST binding, i.e. by including the message in a base64-encoded hidden input field in a HTML form. This form is auto-submitted using simple JavaScript. The original RelayState provided by the SP is also included as a form field. In addition, the IdP notes in the user’s session object that the user is logged in now, so that during future requests the user does not have to enter credentials again. The SAML2 Response message is signed with a DSA private key using XML Signature. The SP is in possession of the corresponding public key to verify the signature. These keys are previously agreed on by the SP and the IdP. The SP’s SAML2 endpoint URI (the target of the HTML Form POST) was provided by the SP in the AssertionConsumerServiceURL of the original SAML2 AuthnRequest message. Example signed SAML2 Response message sent from the IdP to the SP:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response
	Destination="http://localhost/org.eclipse.higgins.saml2idp.test/SAMLEndpoint"
	ID="iiafjpbbfkpphhpfnkanbohbcegheliblnoddlda"
	IssueInstant="2007-12-17T18:44:36.843Z" Version="2.0"
	xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
	xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<samlp:Status>
		<samlp:StatusCode
			Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
	</samlp:Status>
	<Assertion ID="kbmkhjlbadjlcibfolmfnlhjplegkpggeeencjih"
		IssueInstant="2007-12-17T18:44:36.843Z" Version="2.0">
		<Issuer>Test SAML2 IdP</Issuer>
		<Subject>
			<NameID
				Format="urn:oasis:names:tc:SAML:1.1:nameid-format:entity">
				saba
			</NameID>
			<SubjectConfirmation
				Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
		</Subject>
		<Conditions NotBefore="2007-12-16T18:44:36.843Z"
			NotOnOrAfter="2007-12-18T18:44:36.843Z" />
		<AuthnStatement AuthnInstant="2007-12-17T18:44:36.859Z">
			<AuthnContext>
				<AuthnContextClassRef>
					urn:oasis:names:tc:SAML:2.0:ac:classes:Password
				</AuthnContextClassRef>
			</AuthnContext>
		</AuthnStatement>
	</Assertion>
	<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod
				Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" />
			<SignatureMethod
				Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
			<Reference URI="">
				<Transforms>
					<Transform
						Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
				</Transforms>
				<DigestMethod
					Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
				<DigestValue>6wIrA6sV2fz0eJtELJl2LO+u3L4=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>
			MbeqB05rjFY6oYE0r2cVYQAVHOkPBMKIMl9QbnuMc0Mnam8VlWg2+A==
		</SignatureValue>
		<KeyInfo>
			<KeyValue>
				<DSAKeyValue>
					<P>
						nGbDS2akXDlfOO6XN3tgwHom37exdk2rnWxvVIk2OOBCwQCZO/oODk5+jgRG83Wo2cxUSLZBrv9A
						NyGyk/UvJw==
					</P>
					<Q>nQ+bcpo3zBKyLF93OzrhqT23XZs=</Q>
					<G>
						Dcvvn+/rfhYX+Ec9ydVlJD5hGhU5ndFiqPs5aF9aQADc4r2thPHH7H8eHMx3+vJc0rfcj49ya/G4
						6F1RcwDNqQ==
					</G>
					<Y>
						UH5tz/e2nWR7Gfxao/qNqKpK/vgJpMb5ElzGMBrkvxzOtLn3XCC/nF90w7J/SaPqJc9UdbA4+wm2
						pVO6HErZOA==
					</Y>
				</DSAKeyValue>
			</KeyValue>
		</KeyInfo>
	</Signature>
</samlp:Response>

This Response message is base64-encoded and sent to the SP’s SAML2 endpoint via a HTML form:

<form name="form-redirection" action="http://localhost/org.eclipse.higgins.saml2idp.test/SAMLEndpoint" method="post" accept-charset="utf-8">
		
	<textarea style="display:none" name="RelayState">Test relay state!!</textarea>
	
	<textarea style="display:none" name="SAMLResponse">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNhbWxwOlJlc3BvbnNlIERlc3RpbmF0aW9uPSJodHRwOi8vbG9jYWxob3N0L29yZy5lY2xpcHNlLmhpZ2dpbnMuc2FtbDJpZHAudGVzdC9TQU1MRW5kcG9pbnQiIElEPSJpaWFmanBiYmZrcHBoaHBmbmthbmJvaGJjZWdoZWxpYmxub2RkbGRhIiBJc3N1ZUluc3RhbnQ9IjIwMDctMTItMTdUMTg6NDQ6MzYuODQzWiIgVmVyc2lvbj0iMi4wIiB4bWxucz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiIgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIgeG1sbnM6eGVuYz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIj48U2lnbmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1I1dpdGhDb21tZW50cyIvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZHNhLXNoYTEiLz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48L1RyYW5zZm9ybXM+PERpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIi8+PERpZ2VzdFZhbHVlPjZ3SXJBNnNWMmZ6MGVKdEVMSmwyTE8rdTNMND08L0RpZ2VzdFZhbHVlPjwvUmVmZXJlbmNlPjwvU2lnbmVkSW5mbz48U2lnbmF0dXJlVmFsdWU+TWJlcUIwNXJqRlk2b1lFMHIyY1ZZUUFWSE9rUEJNS0lNbDlRYm51TWMwTW5hbThWbFdnMitBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxLZXlWYWx1ZT48RFNBS2V5VmFsdWU+PFA+bkdiRFMyYWtYRGxmT082WE4zdGd3SG9tMzdleGRrMnJuV3h2VklrMk9PQkN3UUNaTy9vT0RrNStqZ1JHODNXbzJjeFVTTFpCcnY5QQpOeUd5ay9Vdkp3PT08L1A+PFE+blErYmNwbzN6Qkt5TEY5M096cmhxVDIzWFpzPTwvUT48Rz5EY3Z2bisvcmZoWVgrRWM5eWRWbEpENWhHaFU1bmRGaXFQczVhRjlhUUFEYzRyMnRoUEhIN0g4ZUhNeDMrdkpjMHJmY2o0OXlhL0c0CjZGMVJjd0ROcVE9PTwvRz48WT5VSDV0ei9lMm5XUjdHZnhhby9xTnFLcEsvdmdKcE1iNUVsekdNQnJrdnh6T3RMbjNYQ0MvbkY5MHc3Si9TYVBxSmM5VWRiQTQrd20yCnBWTzZIRXJaT0E9PTwvWT48L0RTQUtleVZhbHVlPjwvS2V5VmFsdWU+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjxzYW1scDpTdGF0dXM+PHNhbWxwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPjwvc2FtbHA6U3RhdHVzPjxBc3NlcnRpb24gSUQ9ImtibWtoamxiYWRqbGNpYmZvbG1mbmxoanBsZWdrcGdnZWVlbmNqaWgiIElzc3VlSW5zdGFudD0iMjAwNy0xMi0xN1QxODo0NDozNi44NDNaIiBWZXJzaW9uPSIyLjAiPjxJc3N1ZXI+VGVzdCBTQU1MMiBJZFA8L0lzc3Vlcj48U3ViamVjdD48TmFtZUlEIEZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6MS4xOm5hbWVpZC1mb3JtYXQ6ZW50aXR5Ij5zYWJhPC9OYW1lSUQ+PFN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIi8+PC9TdWJqZWN0PjxDb25kaXRpb25zIE5vdEJlZm9yZT0iMjAwNy0xMi0xNlQxODo0NDozNi44NDNaIiBOb3RPbk9yQWZ0ZXI9IjIwMDctMTItMThUMTg6NDQ6MzYuODQzWiIvPjxBdXRoblN0YXRlbWVudCBBdXRobkluc3RhbnQ9IjIwMDctMTItMTdUMTg6NDQ6MzYuODU5WiI+PEF1dGhuQ29udGV4dD48QXV0aG5Db250ZXh0Q2xhc3NSZWY+dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFjOmNsYXNzZXM6UGFzc3dvcmQ8L0F1dGhuQ29udGV4dENsYXNzUmVmPjwvQXV0aG5Db250ZXh0PjwvQXV0aG5TdGF0ZW1lbnQ+PC9Bc3NlcnRpb24+PC9zYW1scDpSZXNwb25zZT4=</textarea>

	<input type="submit" value="Continue...">

</form>

This form appears on a simple screen in the user’s browser and is auto-submitted via JavaScript.

Saml2idp-5.png

Figure 4: The IdP’s SAML2 Response is transmitted to the SP via the SAML2 HTTP POST binding.

The SP receives and checks the SAML2 Response message. In particular, the XML Signature is verified using the preconfigured DSA public key. If the signature is valid and the SAML2 status code provided by the IdP indicates successful authentication, the SP allows the user access to secured resources. The SAML2 Assertion contained in the response contains various useful information such a NameID of the logged in user. The original RelayState provided by the SP is preserved; e.g. it may be used to redirect the user to the originally request URL.

Saml2idp-6.png

Figure 5: The user now has access to the SP's restricted resources.

Flow #2: Subsequent logins

After the user is authenticated at the IdP, the IdP stores this information in the user’s session state and will no longer require the user to provide credentials when the SP issues a SAML2 AuthnRequest message.

Saml2idp-7.png

Figure 6: The user wants to access the SP again.

As before, the SP issues a SAML2 AuthnRequest message to the IdP (via the HTTP Redirect binding), only this time no credentials are required, and the SAML2 Response is sent back to the SP immediately (via the HTTP POST binding).

Saml2idp-8.png

Figure 7: The IdP receives the SP's SAML2 AuthnRequest and immediately answers with a SAML2 Response.

As before, XML Signatures and other aspects of the SAML2 messages are verified, and the user can access the SP’s restricted resources once again.

Saml2idp-9.png

Figure 8: The user is logged in again at the SP.

Flow #3: Username Extraction

Note: This is an additional feature of the Higgins SAML2 IdP and not part of SAML 2.0 specifications.

The "Username Extraction" feature makes it possible for the SAML2 IdP to issue authentication statements for users it does not authenticate itself. Applications for this feature may be SSO scenarios in which some SSO software can authenticate users, but does not itself issue SAML2 authentication statements.

If this feature is activated (see SAML2 IdP Deployment for details on how to configure it), then the username for which an assertion is issued is not entered by the user. Instead it is provided by some application in one of three ways:

  • As the value of a request parameter
  • As the value of a request header
  • As the value of a request cookie

The HTTP request body still has to contain a valid SAML AuthnRequest.

Currently no checks on the originating IP address are performed. This may be a security issue.

Saml2idp-8.png

Figure 9: The IdP receives the SP's SAML2 AuthnRequest. The username is provided in a parameter or header or cookie. The user is authenticated immediately.

Saml2idp-9.png

Figure 10: The user is logged in at the SP.

Configuration

Higgins components are configured using the Higgins Configuration API. Configuration settings on the IdP’s side include the following:

  • A human-friendly name for the IdP that is used in the SAML2 <Issuer> element.
  • The DSA private key used to sign SAML2 messages.
  • IdAS-related settings needed to access the Higgins context against which users are validate.

For more information on how to configure and deploy the SAML2 IdP, see SAML2 IdP Deployment.

Logging

The Apache Commons Logging API is used for logging purposes. All activity at both the Higgins SAML2 IdP and the Higgins Test SAML2 SP is logged. The following text displays logging messages in a typical protocol flow as outlined in this document:

[SP]  INFO: Sending SAML2 AuthnRequest to IdP.
[IdP] INFO: User is not logged in. Displaying credentials form for context type $context+ldap.
[IdP] ATTENTION: Cannot login user: badguy
[IdP] INFO: User admin logged in. Sending SAML2 Response to SP.
[SP]  INFO: SAML2 Response XML Signature verified.
[SP]  INFO: SAML2 Response StatusCode: urn:oasis:names:tc:SAML:2.0:status:Success
[SP]  INFO: User successfully logged in.
[SP]  INFO: Sending SAML2 AuthnRequest to IdP.
[IdP] INFO: User is logged in already. Sending SAML2 Response to SP.
[SP]  INFO: SAML2 Response XML Signature verified.
[SP]  INFO: SAML2 Response StatusCode: urn:oasis:names:tc:SAML:2.0:status:Success
[SP]  INFO: User successfully logged in.

Future Work

The following issues need to be addressed in future versions:

  • Create more Higgins context providers to be able to authenticate against Kerberos, RADIUS, etc.
  • Improve security features (e.g. prevent password guessing attacks, run more checks on the SAML2 messages).
  • Improve the Higgins Configuration API so that existing configuration can be modified programmatically.
  • SAML 2.0 support is limited. Support for more SAML 2.0 is desirable.

Back to the top