IdP credentials for delegation Assertion signature validation

Brent Putman putmanb at georgetown.edu
Wed Aug 19 23:59:31 EDT 2015


Working on wiring up the delegation flow.

One thing we need to be able to do is evaluate the signature on the
inbound Assertion token using a signature trust engine that contains
the IdP's own signing credentials.  Basically, it's verifying a
signature that it itself previously generated.

My initial thought was we could just create a simple list of them based
on the bean(s) define in conf/credentials.xml.  Then it's simple to
just create a trust engine based on a StaticCredentialResolver.

But turns out that we don't actually load that context in the root
Spring context or in any context visible to a flow.  It's just used as
a config resource for the RelyingPartyConfigurationResolver service,
which I guess has its own context.

So, looking for input here.  Should we look at (perhaps redundantly
with the RPCR) loading credentials.xml in the root context to get at
them as visible beans?  Or is there some way to leverage what's already
in the RPCR?  I guess the (horribly complex) way to do the latter would
be to see to whom we issued the Assertion and then attempt to resolve
the creds via the RPCR that would have been candidates for signing.  Or
something like that.  Not sure that that even works.  But definitely
feels like overkill, esp since the number of creds here is very small
(by default 1).  So I was thinking of keeping it simple and just trying
all the IdP creds that are configured.

Btw, for testing I tried just importing conf/credentials.xml in my flow
just to see if I could continue with the flow work, but turns out it
has another reference that also isn't visible - the entityID bean in
system/conf/relying-party-system.xml. So I stopped for now b/c it's
getting out of hand.

Otherwise getting very close to having this flow at least be functional.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150819/d314d08e/attachment.html>


More information about the dev mailing list