RES: dev Digest, Vol 47, Issue 8

Wed May 6 16:26:44 EDT 2015

Hello,

I wonder if there is something to be more clear to me on the Shibboleth.
With documentation can see the Shibboleth is like a monstrous tool, but I need my component is a guy who receives a SAML request, treat the way I have and then return a SAML response.
The Shibboleth, for example, receives a SAML request, comes within your IdP and returns a SAML response, I'm going in the right way?
I'm doing the same thing the Shibboleth or am I doing something totally different.

Another question, SAML is a standard request and response, ok? Or is there some event that such a tool asks for a different SAML request and response in which the Shibboleth has already approved?

Thanks guys and regards,
FULVIO ALMEIDA SILVA

-----Mensagem original-----
De: dev [mailto:dev-bounces at shibboleth.net] Em nome de dev-request at shibboleth.net
Enviada em: quarta-feira, 6 de maio de 2015 13:00
Para: dev at shibboleth.net
Assunto: dev Digest, Vol 47, Issue 8

Send dev mailing list submissions to
	dev at shibboleth.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://shibboleth.net/mailman/listinfo/dev
or, via email, send a message with subject or body 'help' to
	dev-request at shibboleth.net

You can reach the person managing the list at
	dev-owner at shibboleth.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of dev digest..."

Today's Topics:

   1. RE: A maven approach to deploying the Idp (Misagh Moayyed)
   2. FYI Disabled some Jenkins jobs (Tom Zeller)

----------------------------------------------------------------------

Message: 1
Date: Tue, 5 May 2015 15:01:34 -0700 (MST)
From: "Misagh Moayyed" <mmoayyed at unicon.net>
To: "'Shib Dev'" <dev at shibboleth.net>
Subject: RE: A maven approach to deploying the Idp
Message-ID: <0a591e01.00001d9c.0000001c at mmoayyed.unicon.net>
Content-Type: text/plain;	charset="US-ASCII"

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

------------------------------

Message: 2
Date: Tue, 5 May 2015 19:53:42 -0500
From: Tom Zeller <tzeller at dragonacea.biz>
To: Shib Dev <dev at shibboleth.net>
Subject: FYI Disabled some Jenkins jobs
Message-ID:
	<CAMNmQDRJguArnjt-50gw3oi9JiT+9G5iGmwOYs0dfTCNCkHKGg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

The v2 Jenkins jobs which are failing pending parent POM updates have been disabled until that happens to reduce noise.

------------------------------

Subject: Digest Footer

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

------------------------------

End of dev Digest, Vol 47, Issue 8
**********************************