A maven approach to deploying the Idp

[Misagh Moayyed]

Thanks for the assessment. The following comes to mind:

On the subject of maven security, you're perfectly right but there are
workarounds. A maven build can certainly be configured to retrieve
artifacts from a specific repository and no more. My understanding is that
those repository declarations that are defined in the pom take precedence
over maven central. In this example, most artifacts  (with the exception
of maven plugins) are retrieved from the shib maven repo. Central or other
places outside the pom are then tried as a last sort. Central itself can
certainly be "turned off" either via mirror configuration in the pom, or
one can explicitly mark it as disabled. This goes for both artifacts and
plugins of course. Having disabled central for artifacts, I wiped out my
local repo and ran a quick test and no failures popped up. So it seems
like this type of configuration would provide some level of assurance. All
of this can be packaged inside the overlay pom by default available for
download. No deployer mods may be required.

While it's perfectly true that maven does not verify signatures, there are
plugins that can do the job fairly easily. Provided signatures exist, a
plugin can check and compare and produce results that are for example:

[INFO] net.shibboleth.idp:idp-authn-api:3.1.1 PGP Signature OK
KeyId: 0x277EC86A07CEEB8B UserIds: [Tom Zeller <tzeller at dragonacea.biz>]

Coincidentally, I realized that not all artifacts that are bundled in the
webapp carry signatures. An example that the plugin is warning me about is
the hibernate-core dependency, or did you mean artifacts that are produced
by Shib Dev are signed? I did also encounter one whose signature failed,
that is "org.javassist:javassist:3.18.1-GA PGP Signature ERROR" but I have
yet to verify this. 

At any rate, I believe limiting repository selection and checking
signatures are doable, unless of course the transport layer is
questionable as well. Note that of course, to be 100% sure, (and this may
be a chicken-and-egg problem) the plugin that does the checking must
itself be checked but of course, if a shib plugin repository is available
and trusted, then I suppose that work as well. (If artifacts are only
downloaded from a shib repo, then checking signatures may be overkill, but
it can be done nonetheless).

On the subject of redeployments, this is certainly a valid concern. As an
extension to what the IdP does today, an alternative might be to drive the
loading of various configuration files via environment properties, rather
than expecting one wholesome directory to contain everything. So for
example, something like this would work:

<import resource="${idp.system.conf.home}/utilities.xml" />

Where the property is defined in idp.properties or some such that resolves
prior to loading that particular xml file. This implies that while by
default everything is packaged up by the idp in its own context, if I
needed to overwrite the utilities.xml file, I could add that to my overlay
and simply set that property to my file location. This should eliminate
the need for redeployments completely and of course, none of these
to-be-set properties are required. Reasonable defaults could be set y the
idp to reduce config noise in the property file. Note that this "sort of"
circumvents the default overlay mechanism that maven provides, because in
theory, I could set that path to be anywhere I like which may not align
with the original config layout. 

Misagh


-----Original Message-----
From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, May 4, 2015 2:15 PM
To: Shib Dev
Subject: Re: A maven approach to deploying the Idp

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

--
To unsubscribe from this list send an email to
dev-unsubscribe at shibboleth.net