Date: Thu, 28 Mar 2024 12:36:58 +0000 (UTC) Message-ID: <1901096757.6321.1711629418066@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6320_905637276.1711629418063" ------=_Part_6320_905637276.1711629418063 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Software as a Service (SaaS) model of software distribution= often gives rise to the notion of client or customer. For example, sponsor= ed partners in the InCommon Federation usually cater to customers (which ar= e often campuses), but there are non-commercial web apps, like HathiTrust, th= at also fall into the SaaS category.
A frequently asked question from new SaaS providers is: Should I publish= one comprehensive entity descriptor for all my customers or should I publi= sh a separate entity descriptor for each of them? Either is fully supported= by InCommon and selection of one or the other is more an art than a scienc= e. For your convenience, here we provide some information that will help yo= u make an informed decision.
First, there are neither technical nor policy constraints with respect t= o endpoint locations in SP metadata. That is, a single SP entity descriptor= may have any number of endpoints. There are SPs in InCommon metadata with = hundreds of endpoints in a single entity descriptor.
Similarly, there are no technical limits on the number of SP entity desc= riptors a single organization can publish, but there are limits set by poli= cy. Each organization is allowed up to 50 SP entity descriptors in metadata= . Another 50 entity descriptors may be purchased for $1K per year. Here aga= in we have organizations with scores of entity descriptors in metadata. In = fact, one Federation participant has more than 300 SP entity descriptors in= the InCommon metadata aggregate.
So it goes both ways. Which approach is best?
The entity descriptor is the basic unit of policy and interoper= ability. If entity descriptors are handled in a common way for all your cus= tomers, then consolidation into a single entity often makes sense. A questi= on to begin with is, =E2=80=9Cdoes my web app look like one common service = for all customers, or does it look more like an isolated instance of the se= rvice deployed specifically for a given customer?=E2=80=9D
If the web app does not look like one shared service environment for all= customers, then the ability for policy and interoperability to vary by cus= tomer across multiple entity descriptors is valuable. Such an approach offe= rs the greatest flexibility. On the other hand this approach can complicate= documentation and requires more deployment effort for each organization an= d for the service provider itself.
For their part, campuses vary with respect to what they require for vend= or integration. Some want to own the metadata (for business continuity reas= ons) but are happy to delegate the administration of that metadata to the v= endor (and our Federa= tion Manager supports that model). Others prefer a more hands-off appro= ach and would rather leave the management of metadata entirely to the vendo= r. What your customers want (combined with what you, the SaaS provider, are= willing and/or able to provide) will influence your approach to metadata m= anagement.
Consider the following elements in SP metadata:
In each case, ask yourself the question: Is one such element sufficient = for all my customers or does each customer require a unique such element?= p>
Take c= ertificates in metadata, for instance. In SP metadata, such a certifica= te is primarily an encryption certificate. Is the intention to pro= vide each customer (which in this case corresponds to an Identity Provider)= with their own encryption certificate? This depends in part on the technic= al characteristics of your particular deployment, and your deployment=E2=80= =99s privacy model, but note that in the event of a compromise, it is much = easier to replace a certificate for one customer rather than 50 customers. = This should be a major consideration in your decision-making process.
Avoid sharing certificates across entity descriptors. Not only = is this viewed as a poor security practice, but some SAML implementations (= such as AD FS 2.0) will simply not consume two entity= descriptors that contain the same certificate.
As another example, consider user interface elements in metadata. Identity Providers= (IdPs) use these elements to enhance the login and consent pages presented= to their users. If all your customers (i.e., IdPs) share the same entity d= escriptor, there is no opportunity to provide personalized user interface e= lements, which will be viewed by some IdPs as a deployment limitation.
Single logout (SLO) is another area of concern. An SP whose endpoints ar= e based on multiple vhosts within a single entity descriptor should probabl= y avoid SLO. A user who explicitly logs out of one vhost will necessarily b= e logged out of all vhosts, which may or may not be intend= ed. Consequently, SLO works best for SPs with simple entity descriptors bas= ed on a single vhost.
Similar questions may be asked for each type of element in SP metadata.<= /p>
Finally, please note that delegated administration of metadata operates at the leve= l of the entity descriptor. So if you want to spread out metadata managemen= t across multiple administrators, one entity descriptor per customer works = best.