IdPv3 Extension Installation and Configuration

[Cantor, Scott]

On 7/16/14, 1:43 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>
>I need strict mappings between URI locations and a single flow, e.g.
>
>/idp/cas/login
>/idp/cas/serviceValidate
>/idp/cas/proxyValidate
>
>I get that I could register a flow simply by putting it in a
>well-known location, but I didn't see a way to get the mappings right
>without explicitly editing webflow-config.xml.

I think you can do this without that. I wasn't sure, but I checked and we
have user flows defined that have multi-path components.

If you create cas/login in conf/flows, and add your flow as
login-flow.xml, I think the mapping will be automatic.

That's what I was shooting for anyway.


>> You'll also need to plug into relying-party.xml to enable the profiles,
>> unless you don't intend any of the existing configuration machinery to
>>be
>> used.
>
>Not sure I understand "plug into relying-party.xml." I want to trigger
>the attribute resolver, which I guess depends on relying party, but I
>haven't done any research on how I would do that. Can you sketch out
>some steps or suggest something to review for background?

We don't have much written up yet, but I'll try and put together a basic
outline for you (I'm really off work today, so I don't want to get into
that level of depth right now).

At a basic level, we have ProfileConfigurations that all inherit from a
top-level interface, and the relying-party configuration layer that
enables individual profiles and caotures some profile-independent
configuration.

The base SAML flow (saml-abstract-flow.xml) includes actions that near the
beginning do a lookup for the appropriate RelyingPartyConfiguration to
activate for the request, and then they check if the profile that's
running in that flow is active for that RP config, and bail out otherwise.
Then the rest of the fow has access to the configuration material via a
RelyingPartyContext child.

When you don't have signed requests, which is common in SAML, it's basing
the identity of the requester on a self-asserted identity in the request
message, and it does a metadata lookup on that identity, and then it calls
into a Resolver component (the RelyingPartyConfigurationResolver) that
returns the RelyingPartyConfiguration to use, or if there's no metadata
present, it falls into the category of Anonymous.

This is mostly captured in three actions:

InitializeRelyingPartyContexFromSAMLPeer
SelectRelyingPartyConfiguration
SelectProfileConfiguration




We expect different protocols to have differently coded actions to reach
essentially the same outcome, a populated context tree with a
RelyingPartyContext.

We also know that it's very easy to profile SAML metadata for other
profiles like CAS or OpenID, but we expect those implementations to not
necessarily require it.

So "plugging in" really means defining the profile configuration subtype,
creating a bean for it with default settings in relying-party.xml and
adding it to one or more of the RelyingParty configuration beans, and then
having actions that actually make use of it.

-- Scott