Date: Sat, 30 Mar 2024 00:55:39 +0000 (UTC) Message-ID: <451117705.105.1711760139225@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_104_1707492988.1711760139224" ------=_Part_104_1707492988.1711760139224 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
What is this = about?
When registering a service provider's (SP) metadata= , the Site Administrator or Delegated Administrator can indicate support fo= r specific encryption method(s) when processing encrypted SAML assertions a= nd messages. The options are:
AES-128-CBC - Advanced Encryption Standard Cipher Block Chaining, also&= nbsp;known as a =E2=80=9Cblock cipher=E2=80=9D. AES-CBC is widely sup= ported and often the default among SAML software. However, AES-CBC has know= n security flaws and is vulnerable to attack such as a padding oracles attack.
AES-128-GCM - Advanced Encryption Standard Galois/Counter mode.
Consult your software documentation and determine which encryption metho= ds your software supports. Also make sure the software is configured to use= the encryption methods you check in Federation Manager.
See: Why should I make this selection?
Check the following checkbox(es) when editing an SP metadata's Enc= ryption Key in Federation Manager:
AES-128-CBC, the popular and often default encryption method, has = known security vulnerabilities. The InCommon community needs to transition = to AES-128-GCM to keep user data safe. Shibboleth, the most popular IdP sof= tware deployed in higher education, has ann= ounced that it is defaulting to AES-128-GCM as its SAML message encrypt= ion cipher starting with Shibboleth 4.
Making this selection in your SP metadata lets the IdP know which = method(s) your SP supports. Doing so allows the IdP to choose the most secu= re option when issuing an encrypted SAML assertion/message to your SP. = ;
A word about your SP metadata's defaul= t setting during transition
When InCommon introduces SP encryption method signaling support, if your= SP supports encryption, the AES-128-CBC checkbox is= checked by default. The corresponding SAML metadata element indicating AES= -128-CBC support is added to your SP metadata when the metadata is publishe= d. We are doing so because because we believe that all curr= ent InCommon-registered SP's indicating support for encrypted SAML assertio= ns and/or messages already support AES-128-CBC.
If you do nothing, this default behavior signals to an IdP that your sof= tware only supports AES-128-CBC. The IdP will encrypt SAML assertions/messa= ges to your SP using AES-128-CBC. If your software supports AES-128-GCM, be= sure to check the AES-128-GCM checkbox as well so that the IdP will use th= e stronger encryption method.
Assuming your software supports both encryption methods, chec= king both checkboxes ensures that an IdP that can only encrypt using AES-12= 8-CBC can still interoperate with your SP. At the same time, an I= dP supporting AES-128-GCM will prefer that more secure algorithm. The Shibb= oleth 4 IdP, for example, will choose to encrypt using AES-128-GCM if your = SP supports it.
When you select both encryption methods, InCommon will order the metadat= a encryption method listing (i.e., AES-128-GCM is listed first) so that sof= tware defaulting to the first listed encryption method will choose the more= secure option.
If you have especially sensitive information being sent to your SP= , and you have verified that all IdPs you do business with support AES-128-= GCM, you may want to uncheck the AES-128-CBC checkbox and only check the AE= S-128-GCM checkbox.
To learn more about how SAML implementations should handle
(and why I might want to uncheck all boxes?)
If you uncheck all encryption methods, there will be no indication in yo= ur SP metadata regarding encryption method support. An IdP will use its def= ault encryption method to encrypt assertions/messages sent to your SP. = ;
It is conceivable that some IdP products may not parse the <Enc=
ryptionMethod>
SAML metadata element correctly. If you encounter =
this problem, consider unchecking both checkboxes as a workaround to mainta=
in compatibility.
When uploading an encryption key to an SP metadata, checking the box nex=
t to an encryption method adds an additional SAML metadata <Encryp=
tionMethod>
element. It signals to an identity provider (IdP) tha=
t this SP can decrypt SAML messages encrypted using the checked encryption =
method.
... <SPSSODescriptor protocolSupportEnumeration=3D"urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor> <ds:KeyInfo>...RSA key elided...</ds:KeyInfo> <EncryptionMethod Algorithm=3D"http://www.w3.org/2009/xmlenc11#aes128-gcm"/> <EncryptionMethod Algorithm=3D"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> </KeyDescriptor> ... </SPSSODescriptor>
Can't find what you are looking for?