Date: Fri, 29 Mar 2024 12:45:31 +0000 (UTC) Message-ID: <1629967566.7967.1711716331799@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7966_1248922244.1711716331798" ------=_Part_7966_1248922244.1711716331798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page shows how to set up an SP deployment for SAML V2.= 0 Web Browser SSO. The procedures apply to new SPs as well as existing SPs = migrating from SAML V1.1 to SAML V2.0. We assume that your SP sof= tware has the ability to issue SAML V2.0 requests and consume SAML&nbs= p;V2.0 assertions.
Generally speaking, before making any changes to the so= ftware configuration, an SP's metadata is updated for SAML V2.0 and al= lowed to propagate throughout the Federation. Since Web Browser SSO almost = always begins at the SP, exposing endpoints in SP metadata that are not sup= ported in software is usually harmless. On the other hand, issuing SAML&nbs= p;V2.0 requests without appropriate SAML V2.0 endpoints in metadata is= a recipe for disaster!
This section shows how to update metadata and configure the SP software = for SAML V2.0 Web Browser SSO.
Preconditions:
Procedure:
Procedural details:
InCommon metadata is updated at step 1 in advance of configuring th=
e software for SAML V2.0. First add one or more SAML V2.0 endpoin=
ts to metadata, including at least one <md:AssertionConsumerServic=
e>
endpoint and zero or more <idpdisc:DiscoveryResponse&=
gt;
endpoints. See the comprehensive wiki topic on SP Endpoints for requirements and recomm=
endations.
Since a SAML V2.0 IdP typically encrypts assertions transmitted thr= ough the browser, the SP is obliged to add an encryption key to metadata as= well. In the InCommon Federation, this will already be done since a key in= SP metadata is designated as a multiple use key by default. (See the wiki = topic on Key Usage for det= ails.)
At step 2, you must wait for the new metadata to propagate before c= ontinuing with the remaining steps. We recommend you wait at least = three (3) days for the metadata to propagate, but you may have to = wait longer if your partners do not routinely refresh metadata.
At step 3, begin by configuring the software with the private decry= ption key corresponding to the public encryption key in metadata. If an enc= ryption key was already in metadata when you started this procedure, perhap= s the decryption key is likewise already configured in software. Double-che= ck your configuration to be sure.
If the SP deployment will use the SAML V2.0 Identity Provider Disco= very Protocol, the software is configured to issue such protocol requests i= n the presence of an unauthenticated user. Otherwise this configuration ste= p may be omitted in favor of some other approach to IdP discovery.
Finally the software is configured to issue SAML V2.0 authenticatio=
n requests and consume SAML V2.0 assertion responses. One or more endp=
oint configurations are required, depending on the <md:AssertionCo=
nsumerService>
endpoint(s) added to metadata at step 1.
Once the SP has been upgraded to SAML V2.0, a natural tendency is t= est the complete, end-to-end flow. If this works, you may be done, but if i= t doesn't, or you require more thorough testing, a targeted test sequence may be employed:=
Such tests limit the scope of the problem and therefore make bugs easier= to find.