IdPv3 Extension Installation and Configuration

[Cantor, Scott]

On 7/16/14, 10:44 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>
>Installation will consist of copying the artifacts to the appropriate
>locations:
>
>1. Jar -> $idp.home/war/WEB-INF/lib
>2. Spring XML -> $idp.home/conf/cas
>3. Webflow XML -> $idp.home/flows/cas
>4. Views -> $idp.home/views/cas

Assuming subdirectories work in the views, I guess if you use a view name
of cas/foo that works?

>Configuration will require light editing of existing configuration files:
>
>1. Add reference(s) to CAS webflow XML in
>$idp.home/system/conf/webflow-config.xml

I think you can avoid that if you use appropriate naming for your flows.
We have a user-accessible flow repo in conf/flows, and as long as the flow
files follow the right naming convention, it should work. We have
dependencies now on flows there to ensure that functions.

But if you want them to look exactly like the SAML profile flows, that
probably won't work. I'd tend to suggest favoring "don't touch system/"
over most other considerations though.

>2. Update idp.properties as necessary with CAS properties using
>template idp.properties as reference

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. And there may be ripple effects in doing that, there are
dependencies inside the authentication layer on access to
RelyingPartyConfiguration and so forth. Nothing SAML specific, but I don't
know if they work without anything in the context tree for that.

If it works to bypass all that, then I guess it's more of a design
question whether it's best to do that or not. I know from our perspective,
we think protocols should all be *capable* of being secured appropriately,
including endpoint checks, unless they're explicitly activated for the
Anonymous relying party, and then they can do whatever they want if they
have enough information to run.

-- Scott