Custom Santuario Content Resolver

[Cantor, Scott]

On 1/17/12 10:30 AM, "Chad La Joie" <lajoie at itumi.biz> wrote:
>
>One of the upcoming changes[1] in Santuario-J 1.5 is how same-document
>Elements are resolved by ID.  I think we should move to using a custom
>org.apache.xml.security.utils.resolver.ResourceResolver implementation
>that has baked in knowledge of the constraints imposed by the SAML
>signature profile.

It's definitely been the case that people using OpenSAML are failing to
impose the SignatureProfileValidator step, so our fix to the wrapping
issue has helped us, but not so much others.

If we can bake this in in such a way that our code automatically does the
right thing if our basic signature checking APIs are used, that seems like
an improvement.

>Scott can correct me if I'm wrong, but I think those profiles let us
>perform the following additional checks (above just a straight ID
>resolution):
>- that there is only a single, in-document, content reference
>- that the dereference object is always the element that contains the
>signature being checked

I don't know the internals, but it seems like it should.

>Also, I haven't dug in to the encryption profile but it too probably
>provides us with some constraints that we can use to tighten things
>down.

Not really, encryption is not constrained other than by best practices to
ensure key resolution works. The problems there have all been because of
bugs in the algorithms themselves, which doesn't leave much for
applications to do about them. We used to assume that the risk was only
failure to find the right key, but now the whole stack is pretty much
shot. I think we still have to have the discussion about whether to turn
it off by default in V3.

At this point, I anticipate that all the SP can do is limit the attacker
population to anybody with a valid key in metadata. Any trusted IdP can
hack on any other IdP's ciphertext no matter what we implement, unless we
spend the resources to implement AES-GCM in OpenSSL or Santuario.

-- Scott