Date: Thu, 28 Mar 2024 10:56:54 +0000 (UTC) Message-ID: <738628892.6171.1711623414660@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6170_83929137.1711623414658" ------=_Part_6170_83929137.1711623414658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Community Review in progress!
This document contains DRAFT material intended for discussion and commen= t by the InCommon participant community. Comments and questions should be s= ent to the InCommon participants mailing list (participants@incom= mon.org).
Generally speaking, a good rule-of-thumb for new IdPs is to start simple= and add more features and capabilities as the IdP matures and specific nee= ds develop. Experience has shown that seldom used features are often deploy= ed without adequate testing, leading to latent deployment bugs and even sec= urity holes.
The following deployment strategy forces all protocol traffic over the f= ront channel, which is easier to troubleshoot, manage, and maintain.
Later, if an SP partner requires the use of a back-channel SAML protocol, a new = endpoint is easily added to metadata. However, since all new SPs registered= in the Federation today are required to support SAML2 Web Browser SSO on t= he front channel, you may never need these extra SAML features.
An IdP should try to avoid SAML1 if possible, but in any case n= ote the following:
SingleS=
ignOnService
endpoint that supports the proprietary Shibboleth AuthnRequest
binding/protocol.All new IdPs MUST support SAML2 Web Browser SSO. Note the follo= wing specific recommendations:
SingleS=
ignOnService
endpoint that supports the SAML2 HTTP-Redirect binding. Support for other bindings is optional and new deployments ar=
e encouraged to be conservative in this respect.
AttributeService
e=
ndpoint in metadata. (An IdP deployment that routinely pushes attributes do=
es not need to support SAML2 attribute query and doing so might cause spuri=
ous errors at the SP.)To illustrate the above recommendations in terms of metadata, here is a = sample entity descriptor for an IdP that supports SAML2 Web Browser SSO on = the front channel only:
<!-- The Example State University (example.edu) --> <md:EntityDescriptor entityID=3D"https://websso.example.edu/idp" xmlns:m= d=3D"urn:oasis:names:tc:SAML:2.0:metadata"> <md:IDPSSODescriptor errorURL=3D"https://login.example.edu/support.htm= l" protocolSupportEnumeration=3D"urn:oasis:names:tc:SAML:2.0:protocol"> <md:Extensions> <shibmd:Scope xmlns:shibmd=3D"urn:mace:shibboleth:metadata:1.0" re= gexp=3D"false">example.edu</shibmd:Scope> <mdui:UIInfo xmlns:mdui=3D"urn:oasis:names:tc:SAML:metadata:ui">= ; <mdui:DisplayName xml:lang=3D"en">Example State University Se= cure Web Login</mdui:DisplayName> <mdui:InformationURL xml:lang=3D"en">https://login.example.ed= u</mdui:InformationURL> <mdui:Logo height=3D"128" width=3D"128" xml:lang=3D"en">https= ://login.example.edu/images/IdP_Logo.png</mdui:Logo> </mdui:UIInfo> </md:Extensions> <md:KeyDescriptor use=3D"signing"> <ds:KeyInfo xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> MIIDyTCCArGgAwIBAgIJAKivSalalUbnMA0GCSqGSIb... </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:SingleSignOnService Binding=3D"urn:oasis:names:tc:SAML:2.0:bindi= ngs:HTTP-Redirect" Location=3D"https://login.example.edu/idp/saml2/Redirect= /SSO"/> <md:SingleSignOnService Binding=3D"urn:oasis:names:tc:SAML:2.0:bindi= ngs:HTTP-POST" Location=3D"https://login.example.edu/idp/saml2/POST/SSO"/&g= t; </md:IDPSSODescriptor> <md:Organization> <md:OrganizationName xml:lang=3D"en">The Example State University= </md:OrganizationName> <md:OrganizationDisplayName xml:lang=3D"en">Example State Univers= ity</md:OrganizationDisplayName> <md:OrganizationURL xml:lang=3D"en">http://www.example.edu</md= :OrganizationURL> </md:Organization> <md:ContactPerson contactType=3D"technical"> <md:GivenName>Technical Services</md:GivenName> <md:EmailAddress>tech-services@example.edu</md:EmailAddress>= ; </md:ContactPerson> <md:ContactPerson contactType=3D"administrative"> <md:GivenName>Administrative Services</md:GivenName> <md:EmailAddress>admin-services@example.edu</md:EmailAddress&g= t; </md:ContactPerson> </md:EntityDescriptor>
Note the following protocol-related features of this entity descriptor:<= /p>
<md:IDPSSODesc=
riptor>
element.protocolSupportEnumeration
XML attribute indicates SAM=
L2 only.SingleSignOnService
endpoints that support t=
he HTTP-Redirect
and HTTP-POST
bindings (both of =
which are front-channel bindings).If you compare this metadata to the majority of IdP entity descriptors i= n InCommon metadata, you=E2=80=99ll notice the following significant differ= ences:
<md:IDPSSODescriptor>
and <=
;md:AttributeAuthorityDescriptor>
elements.ArtifactResolutionService
endpointsAttributeService
endpointsAttributeS=
ervice
endpointClearly the metadata for an IdP that only supports SAML2 on the= front channel is much simpler. That simplicity translates into an IdP that= is easier to troubleshoot, manage, and maintain.