<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Working on wiring up the delegation flow.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Otherwise getting very close to having this flow at least be
functional.<br>
<br>
</body>
</html>