A maven approach to deploying the Idp

[Cantor, Scott]

On 5/4/15, 4:52 PM, "Misagh Moayyed" <mmoayyed at unicon.net> wrote:

>Everything else is hidden and will be retrieved and packaged up by Maven automatically.

Well, Maven really has no security. Unless you're talking about a local repo, but think you're referring to pulling in the components remotely.

We sort of wink around this with our builds, but at least it's our repository, and what we sign is what people are meant to trust afterward. Maven can't check signatures (they laughed at us when we suggested it, quite a savvy bunch) so that doesn't really extend to doing a build yourself without a lot of work.

It might be viable to ship a maven config that explicitly trusted only the certificate on the repository URL, I suppose. Without that, it's not an appropriate means of deploying security software (that goes for CAS also).

With just a brief look, though, I would say this is the major dealbreaker and is the main reason we didn't do it this way ourselves in some form:

"Redeployments are required for changes, because the IdP runtime is modified to not point to an external location outside the webapp, as it did previously with references to /opt/shibboleth-idp for instance by default, but inside its own context. Therefore, any changes that are applied to a local overlay
need to redeployed and repackaged to be included in the same webapp."

That's a non-starter for any deployment that isn't just a toy. But perhaps this is a way of building demoable installs and/or pilots and could be provided along with the "standard" way.

I'm entirely open to driving the installation in all kinds of ways, and ant is really irrelevant, that was just the least risky way to ship at the time, but the layout of the user-modifiable files is very deliberate. I'm very interested in burying the system/ files though, I just wasn't aware of the classpath:* trick before we shipped.

-- Scott