Delegation Liberty SSOS flow completely broken on Subject C14N
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
Some apparent changes to the way the c14n flows work has broken the Liberty SSOS flow.
In idwsf-ssos-flow.xml, we were doing SAML Subject c14n by calling a subflow like so:
Apparently the flow that was named c14n/saml has gone away. I see in the svn history that it was replaced by a more generic flow named c14n. But that doesn't work, failing with:
2016-10-18 20:11:26,830 - ERROR [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:78] - Profile Action SelectSubjectCanonicalizationFlow: No potential flows left to choose from, canonicalization will fail
That's the only logging I currently get. I'm going to need some guidance, probably from Scott, about what to do here.
If the current c14n is usable as-is, maybe we just need some more context data to be populated in the PRC? In the ProcessDelegatedAssertion action code which immediately precedes the subflow callout, I was setting up for subject c14n like so:
Ok, thx. That seems to work. I'll close this unless I find another problem.
Scott Cantor October 19, 2016 at 12:43 AM
Edited
Missing step is probably PopulateSubjectCanonicalizationContext. Has to be told now which set of c14n flows are available to allow the same driver to run for both SAML and post-login cases, so I wired that into the parent flow.
Probably can just reuse the bean, just need to add that action ahead of the subflow call, probably like this:
Scott Cantor October 19, 2016 at 12:38 AM
Except yes, the name changed, I collapsed them into one master flow, and thought I changed all the callers. I must have thought this was using the abstract SAML flow's call to this subsystem, it's used during queries for one example.
Some apparent changes to the way the c14n flows work has broken the Liberty SSOS flow.
In idwsf-ssos-flow.xml, we were doing SAML Subject c14n by calling a subflow like so:
Apparently the flow that was named
c14n/samlhas gone away. I see in the svn history that it was replaced by a more generic flow namedc14n. But that doesn't work, failing with:That's the only logging I currently get. I'm going to need some guidance, probably from Scott, about what to do here.
If the current
c14nis usable as-is, maybe we just need some more context data to be populated in the PRC? In theProcessDelegatedAssertionaction code which immediately precedes the subflow callout, I was setting up for subject c14n like so: