A maven approach to deploying the Idp

[Misagh Moayyed]

All sounds good. I am sure further experimentation is required to see how
signature verification and repo selection would work. I have updated the
project referenced earlier to note the pgp-plugin configuration and other
related changes. Feel free to test it out.

On the topic of layouts, there are a few more advantages to a
maven-overlay approach that I think would be good to share:

1. For deployments where custom extensions of IdP components may be
required, a developer can feel very much at ease because the overlay
project is already set up for dev. All the dependencies are already
declared (and can be added to) and a structured layout for src/main/java
would mean that components developed can get automatically compiled and be
put on the classpath. Presently, developing such extensions would require
a bit of an elaborate set up. 

2. An overlay configuration does allow overwriting existing classes that
are marked entirely as final. Suppose I wanted to modify the behavior of
component X in IdP and yet X was completely locked. Approaching this from
purely a technical perspective*, what I could do is, rather than starting
from scratch and modifying xml to point to a "new" class, I would obtain a
copy of that class, place it at the exact path in my overlay and only
change the bit I wanted. This is infinitely easier, IMO. The classloader
will know to load mine, rather than what's in the JAR. (Or that has been
my experience with latest of Tomcat 6~8 and Jetty 9)

Sharing one other note regarding app initialization which you may have
stumped upon too: in my initial attempts, I had in mind that I could
entirely get rid of the context initializer by letting Spring do all the
work for me. Have it load all properties via bean config in a default
applicationContext file that Spring knows where to find automatically.
Then in my overlay, I could simply overlay this context file and have it
point to my own property files, which would then attempt to load the
remaining xml config files based on paths that are defined in those props.
This quickly started to get out of hand! as I discovered later on is that
importing bean config via import statements in Spring does not support
property place-holder config as that kicks into effect "after" everything
is loaded...and the property place-holder config does not add to the
environment context (as the initializer does today). Good learning
experience there, and I suppose I could write something that would have
done that, but that just seemed overkill and no different conceptually
than what the initializer does today. So I backed out.

Misagh

* There ought to be very good reasons as for why a locked component needs
modifications, but I am trying set those aside. 
** I am not prejudiced towards Maven :) and I suppose some of the more
script-like tasks in the current overlay pom can easily be done better
with the likes of Gradle. That might be a better approach. (There are
plugins for Gradle as well that do the same overlay thingy)

-----Original Message-----
From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, May 5, 2015 7:19 AM
To: Shib Dev
Subject: Re: A maven approach to deploying the Idp

On 5/5/15, 7:44 AM, "Misagh Moayyed" <mmoayyed at unicon.net> wrote:
>
>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:

It was my understanding no such plugins existed, or if they did they
didn't work quite the way they needed to, but time may have moved on. I
guess the primary issue is whether they will fail the build if the
signatures don't involve a trusted key.

We'll certainly look into it.

>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?

We import everything signed, or sign it ourselves if it's not, but lacking
a plugin checking it, we might have missed one.

>At any rate, I believe limiting repository selection and checking 
>signatures are doable, unless of course the transport layer is 
>questionable as well.

It's very questionable if the basis is commercial TLS.

>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" />

That's probably a good idea just in general rather than relying on layout.

>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.

Yes, that's a good suggestion.

-- Scott

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