encrypt assertion with static AES key

[Brent Putman]

On 4/10/25 3:55 PM, Brent Putman wrote:
>
> In the IdP what you'd need then is support for building a Credential 
> with the key on disk, and I seem to remember implementing something 
> like that, i.e. reading the base64-encoded bits of a symmetric key. 
> Not 100% sure though. Paul, if you really want to try and support it 
> with that SP, I can look to confirm that.
>
>
Yeah, we do support.  Even more surprisingly, it's actually (almost 
entirely) documented in the wiki. :-)

For the Spring Credential factories see here:

https://shibboleth.atlassian.net/wiki/x/mKG0vg

specifically the BasicCredential ones: 
shibboleth.BasicResourceCredentialFactoryBean and 
shibboleth.BasicInlineCredentialFactoryBean. You'd want to configure 
the secretKeyAlgorithm, secretKeyEncoding and secretKeyInfo attributes 
appropriately. Probably also the entityID, if for no other reason than 
documentation purposes. And perhaps also keyNames, if the SP sends a 
ds:KeyName element in the message ds:KeyInfo structure as a hint to the 
specific key used.

Then you'd wire that into an RP-specific config:

https://shibboleth.atlassian.net/wiki/x/PaG0vg

specifically the Per-Profile Credential section. The example there is 
for a signing credential, but the encryption one would be similar in 
structure, just different property names and parent beans on the 
security config object itself. Something like this (untested):

<bean id="ObnoxiousSecurityConfig" 
parent="shibboleth.DefaultSecurityConfiguration">
     <property name="encryptionConfiguration">
         <bean parent="shibboleth.EncryptionConfiguration.GCM" 
p:keyTransportEncryptionCredentials-ref="ObnoxiousVendorCredential" />
     </property>
</bean>

That assumes (in the context of an already insane requirement) that 
they are rational and do use symmetric key wrap. Technically XML 
Encryption and OpenSAML also support forgoing the indirection of the 
key wrap and using a pre-shared key for the data encryption directly, 
but that's considered highly insecure and bonkers (shouldn't encrypt 
multiple messages over time with the same key). So if they want that 
I'd maybe "just say no" ...

I'll leave to your judgement whether you actually want to attempt to 
acquiesce to this vendor's highly atypical requirement. :-)

--Brent



||
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250410/5550dec9/attachment.htm>