PostAuthenticationFlows for non-SAML profiles

[Misagh Moayyed]

Yes, that helps. Thank you. I was wrong to assume that calling the authn
subflow would auto-trigger those post-authn flows. It does, but only
because that intercept action is wired into the executing flow which seems
to be applied to SAML flows only. Once I modified the OIDC flow to call on
actions to resolve, filter and process intercepts, I was able to get it to
work. 

So a few more questions:

The attribute-release screen shows me a set of attributes that are going
to be released to service. It doesn't list which "service". Cognitively, I
know what service that is but it would be better if the screen actually
listed that. Possible? 

Moreover, does it make sense for the Idp to actually tell the user where
they would be going if they press Accept/Authorize? Show a URL on the page
that says "This is where you'll end up if you press X"? 

Is there a way for the same screen to show how many times the service has
been approved, previously? 

Can the same screen remember my choice for a configurable period of time?

It seems like the attribute release function is all or nothing. You either
accept to release everything or you do not. Is there ever a need to have
the user selectively decide which attributes may be release? Or are we
assuming that whatever comes out of the filter decided by the IdP deployer
is absolutely required and I don't get a say? I ask, because I might be OK
with releasing my userid, but don't necessarily wouldn't want to release
my physical address. Some of these attributes may be purely optional, used
to reconstruct my profile for the SP. 

This bit isn't what I am going to work on anytime soon but I wonder; the
approval page generally may explain how the service was recognized by the
identity provider. Was it explicitly defined? Was is dynamically
registered? Etc. Can that be worked into the screen? If you have for
example dynamic metadata wired into the Idp, it would be good to show on
the same screen that "this service came from X, and it was registered Y
minutes ago", etc. This is more of a nice-to-have, and can be tabled for
now. 

Misagh 

> -----Original Message-----
> From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
> Sent: Thursday, August 20, 2015 2:01 PM
> To: Shib Dev <dev at shibboleth.net>
> Subject: Re: PostAuthenticationFlows for non-SAML profiles
> 
> On 8/20/15, 4:02 PM, "dev on behalf of Misagh Moayyed" <dev-
> bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:
> 
> >How does one define post-authentication flows for an IdP profile config
> that is not SAML based? Do I need to simply define getters/setters for
> those flows and the IdP would pick them up when that profile is
activated,
> or is there more I need to do?
> 
> I think you're asking about the ProfileConfiguration beans? I defined a
> base interface called AuthenticationProfileConfiguration and that's
where
> the getter is declared, and then I implemented it in the relevant SAML
> profile config classes.
> 
> But as far as making it get used, that's specifically wired into the
> relevant flows, with the set of intercepts to run pulled from the
> AuthenticationProfileConfiguration interface at runtime.
> 
> <bean id="PopulatePostAuthnInterceptContext"
> 
>
class="net.shibboleth.idp.profile.interceptor.impl.PopulateProfileIntercep
> torContext" scope="prototype"
>             p:availableFlows-ref="shibboleth.AvailableInterceptFlows">
>         <property name="activeFlowsLookupStrategy">
>             <bean
>
class="net.shibboleth.idp.authn.config.navigate.PostAuthenticationFlowsLoo
> kupFunction" />
>         </property>
>     </bean>
> 
> That bean uses a lookup function to populate the flows to run, and that
> function pulls from that interface.
> 
> 
> Does that answer the question?
> 
> -- Scott
> 
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net