PostAuthenticationFlows for non-SAML profiles

[Cantor, Scott]

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