Date: Fri, 29 Mar 2024 09:17:48 +0000 (UTC) Message-ID: <1841163016.23.1711703868542@wiki-prod.refeds.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_22_777534541.1711703868538" ------=_Part_22_777534541.1711703868538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page aims to guide Feder= ation Operators in supporting the adoption of the Sirtfi Framework.
During the process of Sirtfi adoption, federation operators should=
anticipate providing support to entities. An FAQ The Sirtfi Framework does not itself entitle federation operators =
to limit which of their entities may self-attest to Sirtfi compliance, alth=
ough Sirtfi also does not place any constraint on policies that each federa=
tion chooses to adopt. Please reach out to your REFEDS contacts should you, as a federati=
on operator, require assistance. If you have no active members within REFED=
S, contact us via contact@refeds.org and =
ask for the Sirtfi Working Group. Your federation may wish to provide specific guidance on the choic=
e of Sirtfi Contact. For more information, visit =
Choosing a Sirtfi Contact. Should your federation already provide centralised federated secur=
ity incident response, you may choose to leverage this existing capability.=
How should your federation participants add the two required exten=
sions to their metadata? The Guide =
for Federation Participants describes the two extensions i=
n further detail. Be sure to communicate how an entity should assert their complianc=
e and add their Sirtfi contact. Usually, federations choose to manage such =
metadata extensions centrally and act as the registrar. They would simply r=
equest the Sirtfi contact details from an entity via email. Both original Sirtfi (v1) and Sirtfi v2 will remain supported for =
the indefinite future. There is no plan to deprecate v1 with the introducti=
on of v2. See Coexistence of Sirtfi v1 and v2 for details. B=
est practice is to encourage adoption of Sirtfi v2 by your members but to s=
upport those members who wish to remain at v1. For reference: Sirtfi v1 specification and Sirtfi v2 specification Sample outreach letters have been provided below to assist with co=
mmunication to your federation. Many thanks to Incommon and REN-ISAAC for t=
heir input. Dear Federation Members, <THIS FEDERATION>, alongside international partners, strongl=
y urge federation participants to be ready to manage federation-related sec=
urity incidents. Here=E2=80=99s how. Sirtfi [1] is an international framework for federated security in=
cident response. It specifies a means to publish your readiness for inciden=
t response in federation metadata. This framework asks that each federation=
entity, ie, Identity and Service Providers, contain security contact infor=
mation in its federation metadata; that normal security incident response p=
rocedures associated with it reasonably address the statements in the Sirtf=
i specification; and if so, that a Sirtfi tag is attached to the entity. <THIS FEDERATION> recently made self-management of the secur=
ity contact and Sirtfi flag available. Participant Site Administrators can =
now manage Sirtfi status for all systems that are part of the Federation. P=
lease ask them to ensure that your security contact information is correctl=
y expressed in federation metadata and to set the Sirtfi flag if you believ=
e that your security incident response procedures reasonably meet the state=
ments in the Sirtfi specification. Academic collaborations, cloud services, and other uses depend on =
sensitive resources, such as unique instruments, software, high performance=
data processing environments, and corpi of data, being accessible through =
global federation. Most <THIS FEDERATION> participants are home to fa=
culty, students, and staff that need to use these services to be successful=
in their endeavours. Please help them to succeed by being prepared to mana=
ge a federated security incident that could otherwise threaten valuable res=
ources. We invite you to join the Security Incident Response Trust Framewo=
rk for Federated Identity, Sirtfi. To improve security within <THIS FEDERATION>, and across edu=
GAIN, a trust framework has been defined that addresses concerns over opera=
tional security and incident response. By becoming Sirtfi compliant, your o=
rganisation will raise its level of assurance; Sirtfi creates an improved l=
evel of trust between federation participants resulting in increased collab=
oration between federated entities. To find out more about Sirtfi, visit the homepage at To become Sirtfi compliant, refer to the Sirtfi Technical Wiki at<=
/span> https://wiki.refeds.org/display/SIRTFI/SIRTF=
I+Home We recommend choosing <guidance on Sirtfi contact choice> as=
your Sirtfi contact. Two metadata extensions are required to become Sirtfi compliant, &=
lt;we will manage these changes centrally||these should be added to your or=
ganisation=E2=80=99s metadata directly> <ANY OTHER INFORMATION> Regards, The assertion of Sirtfi compliance for a Relying Party is expresse=
d in metadata with the use of an Entity Attribute [1] as described in the O=
ASIS documentation for asserting compliance with assurance profiles [2]. Th=
e validation strategy for local federation entity metadata might need to be=
reconsidered in order to allow local Entities to assert Sirtfi compliance.=
Additionally, if a federation has a filtering procedure in place while rep=
ublishing eduGAIN metadata, federator operators need to ensure that their f=
iltering strategy is adapted in order to facilitate the use of Sirtfi.Sirtfi Con=
tact Choice
Metadata Ex=
tensions
Sirtfi and S=
irtfi v2
Sample Outreach Letter for Federation Participants=
h2>
Enti=
ty Attributes Filtering
Two additions are necessary in the metadata of an entity asserting= Sirtfi compliance so federation operators should focus on whitelisting/all= owing the following :
Sirtfi compliance is expressed with the use of the Entity At= tribute =E2=80=9Curn:oasis:names:tc:SAML:attribute:assurance-certification= =E2=80=9D holding the values of https:/= /refeds.org/sirtfi and https://refeds.org= /sirtfi2 (if SirtfiV2 is met) in an entity=E2=80=99s metad= ata as seen below:
<md:E= ntityDescriptor xmlns:md=3D"urn:oasis:names:tc:SAML:2.0:metadata" ...> <md:Extensions> <mdattr:EntityAttributes xmlns:mdattr=3D"urn:oasis:na= mes:tc:SAML:metadata:attribute"> <saml:Attribute xmlns:saml=3D"urn:oasis:n= ames:tc:SAML:2.0:assertion" NameFormat=3D"urn:oasis:name= s:tc:SAML:2.0:attrname-format:uri" Name=3D"= urn:oasis:names:tc:SAML:attribute:assurance-certification"> <saml:AttributeValue>https= ://refeds.org/sirtfi</saml:AttributeValue> <saml:AttributeValue>https://refeds.org/sirtfi2</saml:Attr= ibuteValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> ... </md:EntityDescriptor>
A security contact element is added in every Entity that asserts S= irtfi compliance as seen below:
REFEDS security contact
<md:C= ontactPerson xmlns:remd=3D"http://refeds.org/metadata" contactType=3D"other" =09remd:contactType=3D"http://refeds.org/metadata/contactType/security"> <md:GivenName>Security Response Team</md:GivenName> <md:EmailAddress>mailto:security@xxxxxxxxxxxxxxx</md:E= mailAddress> </md:ContactPerson>
Multiple EmailAddress tags may be defined should an organisation w= ish to add both a generic email address and an individual.
This contactType has been defined within the REFEDS XSD Metadata E= xtension Schema.
[1] http://docs.oasis-open.org/security/saml/Post2.0/sstc-metada= ta-attr.html
[2] http://docs.oasis-open.org/security/saml/Post2.0/sst= c-saml-assurance-profile.pdf