Date: Fri, 29 Mar 2024 09:14:59 +0000 (UTC)
Message-ID: <1086581122.7751.1711703699120@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_7750_176821233.1711703699117"
------=_Part_7750_176821233.1711703699117
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Per-Entity Metadata Risks and Opportunities
Per-Entity Metadata Risks and Opportunities
- Security
- Disclosure of private key
- Clients not checking signatures
- Intrusion into signing infrastructure
- DoS attacks on distribution
- Availability
- The distribution service for entities
- As discussed in Agenda and Notes - 2016-08-03, it seems feasible that a cost-effe=
ctive infrastructure can be deployed that can provide at least four nines a=
vailability and sufficient capacity for InCommon.
- The aggregation/signing service
- This is not a major concern, assuming a separate distribution layer in =
the architecture.
- Responsiveness / Capacity
- Capacity is not sufficiently elastic
- As discussed in Agenda and Notes - 2016-08-03, it seems feasible that a cost-effe=
ctive infrastructure can be deployed that can provide at least four nines a=
vailability and sufficient capacity for InCommon.
- (We should decide on acceptable response from the distribution service.=
)
- Cost
- Cost of elastic capacity not budgeted
- UK experience indicates that this should be low, a few hundred dollars =
per month.
- Staff time and attention
- Window of opportunity to engage SAML infrastructure components/tools/li=
braries outside of the usual suspects (Shibboleth, SimpleSAMLphp) to suppor=
t Federation (large 'F') using MDQ. See this email from Michael Domingues (Iowa) with a fuller explanation.
------=_Part_7750_176821233.1711703699117--