PostAuthenticationFlows for non-SAML profiles

[Misagh Moayyed]

Well, unless I am misunderstanding the change, the problem is that
attribute-release template can only retrieve the RelyingPartyUIContext
based on that lookup function. So, before I call that subflow I'd have to
populate the context tree such that the lookup is successful. When that
view renders, this is what happens:

<evaluate
expression="SetRPUIInformation.getRPUIContextCreateStrategy().apply(opensa
mlProfileRequestContext)" result="viewScope.rpUIContext" />

So in my own flow where that context is prepped, I'd have do something
like:

SAMLPeerEntityContext samlPeerEntityContext =
profileRequestContext.getOutboundMessageContext().getSubcontext(SAMLPeerEn
tityContext.class, true);

SAMLMetadataContext mdCtx = new SAMLMetadataContext();
mdCtx.setEntityDescriptor(...);

RelyingPartyUIContext rpUI = new RelyingPartyUIContext();
rpUI.setRPEntityDescriptor(...);
mdCtx.addSubcontext(rpUI);

samlPeerEntityContext.addSubcontext(mdCtx);

Right? 

I am not entirely convinced this is the right approach. For one, my
outbound context isn't rightly initialized. 

> -----Original Message-----
> From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
> Sent: Friday, August 21, 2015 10:06 AM
> To: Shib Dev <dev at shibboleth.net>
> Subject: Re: PostAuthenticationFlows for non-SAML profiles
> 
> On 8/21/15, 12:36 PM, "dev on behalf of Misagh Moayyed" <dev-
> bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:
> 
> >So for displaying, I took a look at the velocity template, and I see it
> attempts to pull pieces out of RPUI which of course is
> SAMLMetadataContext-relevant.
> 
> Yes. I guess we might want to consider abstracting that later, but in
the
> meantime as I told Marvin when the CAS work was being discussed, you can
> always create metadata objects that have no XML reality to them, just
> objects to express the right subobjects or attributes so that existing
> code will just work.
> 
> Meaning, you can always call RPUIContext.setRPEntityDescriptor or
whatever
> with objects that are explicitly created to express the data you want
> displayed.
> 
> > So support for it seems to be there; I just need to figure out how to
> >inject that info into the context hierarchy to make it display the same
> bits. The lookup context strategy looks something like this:
> 
> Well, you mean the PopulateRPUIContext action (or whatever it's called).
> Yes, that is metadata based, but yours doesn't necessarily have to be.
For
> SAML metadata-driven profiles, that makes it all "automatic", but you
> could do something more deliberate to populate the context for now.
> 
> >Any suggestions as to how I can prepare the profile context to
> >accommodate that? How would you translate that compose() call? Does it
> >say "looks up the child context that is of type SAMLMetadataContext,
> >and then look up its SAMLPeerEntityContext based on the outbound
> >message context of the profile"? As you can tell, I am very confused :)
> 
> I don't think you need or want to try and create a function like that,
for
> now (see above). But as far as what it's doing, the function composition
> is just saying to access the SAMLMetadataContext child of the
> SAMLPeerEntityContext child of the OutboundMessageContext of the PRC.
> 
> PRC->OutboundMessageContext>SAMLPeerEntityContext->SAMLMetadataContext
> 
> Since you're not dealing with a SAML Peer, none of that really fits
right
> now. Eventually, the consistent thing to do would be to create an
> OpenIDPeerEntityContext. There could still be a SAMLMetadataContext
under
> that if metadata were being used. Or some other kind of metadata
context.
> 
> THe idea with the context trees was to just create new context classes
for
> each new type of data rather than try and build inheritance hierarchies
> that in the past never worked.
> 
> >I do agree with Rod that there are complications in figuring out what's
> >required and what is not in terms of released attributes, but I also
> >think delegating that decision to the user would be OK.
> 
> It's only OK if the user is clueful (strike 1) and if the user has
> adequate information at hand to make the decision (strike 2). But that's
a
> deployer choice, if you want per-attribute checkboxes, you can turn that
> property on (idp.consent.allowPerAttribute).
> 
> -- Scott
> 
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net