...
The servlet creates and sends a an HTTP redirect to the user browser, which points to the Identity Provider. An example looks like below (the encoded request is abridged for clarity):
...
If the authentication was successful, the IdP creates a SAML-Response.
| Expand |
|---|
| title | This is a piece of XML looking like this: |
|---|
|
| Code Block |
|---|
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="https://jira01.lab.inserve.local/plugins/servlet/samlsso" ID="_2b176e8e-306f-41ff-a270-6c31912da25d" InResponseTo="fpfphpacfcmenaooalnnkkdolgpnnajhjgkiaeop" IssueInstant="2015-02-06T19:12:54.168Z" Version="2.0">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://dc01.ad.lab.inserve.local/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_c8a8f7cc-2ecf-44fe-bb9d-c0690a8d4215" IssueInstant="2015-02-06T19:12:54.168Z" Version="2.0">
<Issuer>http://dc01.ad.lab.inserve.local/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#_c8a8f7cc-2ecf-44fe-bb9d-c0690a8d4215">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>GprR3FWR3i2x+Gu/dxSJUj1pElL9l2OsnzGPZFG2XKM=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>fQBzUop+[...]YsoCI/Qgg==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>YAS[...]tU3Qmo9/QQyr7zxBTVsQBNp7H1Mi69gIw==</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID>sam</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="fpfphpacfcmenaooalnnkkdolgpnnajhjgkiaeop" NotOnOrAfter="2015-02-06T19:17:54.168Z" Recipient="https://jira01.lab.inserve.local/plugins/servlet/samlsso"/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2015-02-06T19:12:54.168Z" NotOnOrAfter="2015-02-06T20:12:54.168Z">
<AudienceRestriction>
<Audience>https://jira01.lab.inserve.local/plugins/servlet/samlsso</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2015-02-06T16:47:19.213Z" SessionIndex="_c8a8f7cc-2ecf-44fe-bb9d-c0690a8d4215">
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response> |
|
The important part here is the <Subject>-Tag, especially the containing <NameID>-Tag: The containing data (sam in this example) is considered as the userid to login.
Step 7: The IdP returns a an HTML form
If the authentication succeeds, the IdP returns a an HTML form. This form contains the BASE64-encoded response from step 6 and the SAMLSSO-Servlet-URL (https://<baseurl>/plugins/servlet/samlsso) as destination URL. It also contains a piece of JavaScript which lets the browser submit this form instantly (so the user usually never sees itwill not see the form).
Step 8: The plugin validates the response and extracts the userid.
...