Date: Thu, 28 Mar 2024 14:57:17 +0000 (UTC) Message-ID: <741396633.1.1711637837875@61a21ae0b267> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_0_175348180.1711637837856" ------=_Part_0_175348180.1711637837856 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Before configuring the IdP to communicate with a service provider be sur= e you have a basic understanding of how the I= dP categorizes and works with service providers. You may also want to famil= iarize yourself with the general structure of SAML Metadat= a.
In most cases enabling communication with a service provider requires:= p>
Loading the SP's metadata can be accomplished in a couple different ways= . First, and easiest, is for the service provider to register with a federa= tion whose metadata is already being loaded by the IdP. In this case the Id= P will receive the SPs metadata at its next metadata refresh (this occurs o= nce a day by default). Alternatively the IdP may establish some bilateral p= rocess for receiving the SPs metadata. For example, it may use the file-backed HTTP metadat= a provider to retrieve it from an SP provided URL.
Some service providers, especially those using something other than the = Shibboleth Service Provider software, require special tuning of the message= s that are sent to them (e.g. attributes pushed to them during the sign on = process, certain messages signed or encrypted). These sorts of configuratio= ns may be set by creating per service provider configurations.