PostAuthenticationFlows for non-SAML profiles
Cantor, Scott
cantor.2 at osu.edu
Mon Aug 24 10:10:54 EDT 2015
On 8/24/15, 4:40 AM, "dev on behalf of Misagh Moayyed" <dev-bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:
>Well, unless I am misunderstanding the change, the problem is that
>attribute-release template can only retrieve the RelyingPartyUIContext
>based on that lookup function.
That's true, which is a problem with CAS also, so we need to fix that anyway. Please file an issue on that and we can work out the best way to make that profile-specific. Not sure yet how to address it.
>So in my own flow where that context is prepped, I'd have do something
>like:
As a temporary workaround to get it running, yes, but I agree that's not what we want. The SAMLMetadataContext part is ok because right now the UI context is specific to SAML metadata's data abstraction (though not the actual use of it), but we shouldn't require the SAML peer context for non-SAML profiles.
>I am not entirely convinced this is the right approach. For one, my
>outbound context isn't rightly initialized.
Well, by design it's relying on the assumption that whatever needs to be established outbound is there, but what it *should* be looking for is an OpenIDPeerContext or some such in place of the SAML one.
So we need to make the lookup function there dynamically injected from context at minimum, or make the "peer" class type pluggable, etc.
-- Scott
More information about the dev
mailing list