PostAuthenticationFlows for non-SAML profiles

[Misagh Moayyed]

Done: https://issues.shibboleth.net/jira/browse/IDP-797

Thanks for your patience. 

> -----Original Message-----
> From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
> Sent: Monday, August 24, 2015 7:11 AM
> To: Shib Dev <dev at shibboleth.net>
> Subject: Re: PostAuthenticationFlows for non-SAML profiles
> 
> 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
> 
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net