SAML2 IdP Overview 1.0

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.

See SAML2 IdP Deployment 1.0 for information on how to deploy and configure the two web applications, and see SAML2 IdP Development 1.0 for information on how to check out and build the source code of the involved Higgins components.

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/).

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:

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="#ccocfkmlnocbajegpiheahonbcambbapiibggije">
				<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.

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

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

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:7080/org.eclipse.higgins.saml2idp.test/SAMLEndpoint"
	ID="pipcbfaldmknbdfhpemoffdgeleicplacgfkmgba"
	IssueInstant="2008-06-06T18:28:16.468Z" 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#">
	<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="#pipcbfaldmknbdfhpemoffdgeleicplacgfkmgba">
				<Transforms>
					<Transform
						Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
				</Transforms>
				<DigestMethod
					Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
				<DigestValue>wXkUdimQMvXfCz8Gp5yySnG3k/g=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>
			i4jwSc3oniz7eiuO1lgOmvwQY68pf5ufXQ6va6h+hnyCx7rx5eTS4Q==
		</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:Status>
		<samlp:StatusCode
			Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
	</samlp:Status>
	<Assertion ID="oohonlmfabibplndldcondhfgijdbgigflomeaal"
		IssueInstant="2008-06-06T18:28:16.468Z" Version="2.0">
		<Issuer>Test SAML2 IdP</Issuer>
		<Subject ID="deljjkfbbjplgmpjpdkbljnloebhcmokkhfpkbdl">
			<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 ID="gebdiopkfbeifcjfejemkkemifcaoedmalcffbnh"
			NotBefore="2008-06-05T18:28:16.468Z"
			NotOnOrAfter="2008-06-07T18:28:16.468Z" />
		<AuthnStatement AuthnInstant="2008-06-06T18:28:16.468Z"
			ID="geebkkdmfpnlfkhhkipgpodjomiedepikkifdfkp">
			<AuthnContext>
				<AuthnContextClassRef>
					urn:oasis:names:tc:SAML:2.0:ac:classes:Password
				</AuthnContextClassRef>
			</AuthnContext>
		</AuthnStatement>
	</Assertion>
</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.

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.

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.

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).

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.

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 1.0 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.

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.

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

Security

The SAML2 IdP performs a number of checks to decide whether or not to accept incoming AuthnRequests and whether or not to authenticate the user. In particular, it may be desirable to only allow requests coming from known service providers. For this use case, the following two security features are offered:

• Signed requests: If an incoming SAML2 AuthnRequest contains an XML signature, the SAML2 IdP attempts to verify it using a public key included in a <KeyInfo> element (if present). In addition, the SAML2 IdP can be configured to only accept requests whose signatures can be verified using previously agreed-on keys.
• ACS URL list: Every incoming SAML2 AuthnRequest contains an ACS URL (this is the endpoint to which the SAML2 Response is delivered). The SAML2 IdP can be configured to allow only requests containing an ACS URL from a preconfigured list.

The following diagram outlines the general flow in the SAML2 IdP and shows how the "signed requests", "ACS URL list" and "username extraction" features play together:

Configuration

Higgins components are configured using the Higgins Configuration API. The SAML2 IdP's configuration consists of general SAML settings as well as settings specific to the used Higgins context (e.g. LDAP).

For detailed information on how to configure the SAML2 IdP, see SAML2 IdP Deployment 1.0.

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 initializing:

DEBUG org.eclipse.higgins.saml2idp.test.Init  - init()
INFO  org.eclipse.higgins.saml2idp.test.Init  - Loaded application properties.
INFO  org.eclipse.higgins.saml2idp.test.Init  - Loaded RP private key (algorithm: DSA, format: PKCS#8
INFO  org.eclipse.higgins.saml2idp.test.Init  - Loaded RP certificate from issuer: CN=Markus Sabadello, O=Parity, L=Needham, ST=Massachusetts, C=US
INFO  org.eclipse.higgins.saml2idp.test.Init  - Loaded RP public key (algorithm: DSA, format: X.509
INFO  org.eclipse.higgins.saml2idp.test.Init  - Loaded IdP certificate from issuer: EMAILADDRESS=msabadello@parityinc.net, CN=Markus Sabadello, OU=Higgins, O=Parity Communications, L=Vienna, ST=Some-State, C=AT
INFO  org.eclipse.higgins.saml2idp.test.Init  - Loaded IdP public key (algorithm: DSA, format: X.509)
INFO  org.eclipse.higgins.saml2idp.test.Init  - Up and running.

IdP initializing:

DEBUG org.eclipse.higgins.saml2idp.server.Init  - init()
INFO  org.eclipse.higgins.saml2idp.server.Init  - Loaded application properties.
INFO  org.eclipse.higgins.saml2idp.server.Init  - Loaded IdP private key (algorithm: DSA, format: PKCS#8
INFO  org.eclipse.higgins.saml2idp.server.Init  - Loaded IdP certificate from issuer: EMAILADDRESS=msabadello@parityinc.net, CN=Markus Sabadello, OU=Higgins, O=Parity Communications, L=Vienna, ST=Some-State, C=AT
INFO  org.eclipse.higgins.saml2idp.server.Init  - Loaded IdP public key (algorithm: DSA, format: X.509
INFO  org.eclipse.higgins.saml2idp.server.Init  - Found 1 RP certificates.
INFO  org.eclipse.higgins.saml2idp.server.Init  - Loaded RP certificate from issuer: CN=Markus Sabadello, O=Parity, L=Needham, ST=Massachusetts, C=US
INFO  org.eclipse.higgins.saml2idp.server.Init  - Loaded RP public key (algorithm: DSA, format: X.509)
INFO  org.eclipse.higgins.saml2idp.server.Init  - Found 1 acceptable ACS URLs.
INFO  org.eclipse.higgins.saml2idp.server.Init  - ACS URL: http://localhost/org.eclipse.higgins.saml2idp.test/SAMLEndpoint
INFO  org.eclipse.higgins.saml2idp.server.Init  - Loaded Higgins configuration.
INFO  org.eclipse.higgins.saml2idp.server.Init  - IdAS initialized.
INFO  org.eclipse.higgins.saml2idp.server.Init  - Up and running.

Flow #1 between SP and IdP:

DEBUG org.eclipse.higgins.saml2idp.test.Login  - doPost()
INFO  org.eclipse.higgins.saml2idp.test.Login  - Sending SAML2 AuthnRequest to IdP.
DEBUG org.eclipse.higgins.saml2idp.test.Init  - getSAML2IdPEndpoint()
DEBUG org.eclipse.higgins.saml2idp.test.Init  - getSAML2ProviderName()
DEBUG org.eclipse.higgins.saml2idp.test.Init  - getSAML2Issuer()
DEBUG org.eclipse.higgins.saml2idp.test.Init  - getSAML2SPEndpoint()
DEBUG org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - doGet()
DEBUG org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - processRequest()
INFO  org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - The SAML2 AuthnRequest's signature has a KeyInfo element. We try to use this to verify the signature.
INFO  org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - SAML2 AuthnRequest XML Signature successfully verified with KeyInfo element.
INFO  org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - SAML2 AuthnRequest contains a signature. Checking if we have a matching RP certificate.
INFO  org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - SAML2 AuthnRequest XML Signature successfully verified with certificate from CN=Markus Sabadello, O=Parity, L=Needham, ST=Massachusetts, C=US
INFO  org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - Accepting the SAML2 AuthnRequest.
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getExtractUsernameParameterName()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getExtractUsernameHeaderName()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getExtractUsernameCookieName()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getHigginsContextType()
INFO  org.eclipse.higgins.saml2idp.server.SAMLEndpoint  - User is not logged in. Displaying credentials form for context type $context+ldap.
DEBUG org.eclipse.higgins.saml2idp.server.LDAPLogin  - doPost()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getHigginsContextId()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getHigginsContextFactory()
WARN  org.eclipse.higgins.saml2idp.server.LDAPLogin  - Cannot login user: javax.naming.AuthenticationException: [LDAP: error code 32 - No Such Object], Username=badguy (fail #1).
DEBUG org.eclipse.higgins.saml2idp.server.LDAPLogin  - doPost()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getHigginsContextId()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getHigginsContextFactory()
INFO  org.eclipse.higgins.saml2idp.server.LDAPLogin  - User saba logged in. Sending SAML2 Response to SP.
INFO  org.eclipse.higgins.saml2idp.server.util.SAMLUtil  - Creating SAML Response for destination http://localhost/org.eclipse.higgins.saml2idp.test/SAMLEndpoint with relaystate Test relay state!!
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getSAML2Issuer()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getSAML2AssertionValidityMillis()
DEBUG org.eclipse.higgins.saml2idp.server.Init  - getSAML2AssertionValidityMillis()
INFO  org.eclipse.higgins.saml2idp.server.util.SAMLUtil  - http://localhost/org.eclipse.higgins.saml2idp.test/SAMLEndpoint
DEBUG org.eclipse.higgins.saml2idp.test.SAMLEndpoint  - doPost()
INFO  org.eclipse.higgins.saml2idp.test.SAMLEndpoint  - SAML2 Response XML Signature verified with certificate from EMAILADDRESS=msabadello@parityinc.net, CN=Markus Sabadello, OU=Higgins, O=Parity Communications, L=Vienna, ST=Some-State, C=AT
INFO  org.eclipse.higgins.saml2idp.test.SAMLEndpoint  - SAML2 Response StatusCode: urn:oasis:names:tc:SAML:2.0:status:Success
INFO  org.eclipse.higgins.saml2idp.test.SAMLEndpoint  - SAML2 Response NameID: saba
INFO  org.eclipse.higgins.saml2idp.test.SAMLEndpoint  - 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.