OpenSAML Velocity templates for POST etc. responses

Thu Feb 14 00:17:42 EST 2013

On Jan 3, 2013, at 10:27 PM, Cantor, Scott wrote:

> On 1/3/13 11:01 PM, "Michael A Grady" <mgrady at unicon.net> wrote:
>> 
>> Scott, do you think the Shib Dev team would consider adding a
>> 'classes/templates' directory to the 'src/main/webapp/WEB-INF' directory
>> of the Shib IdP distribution, with four sample Velocity templates that
>> could be used to override the OpenSAML ones? Have them named the same,
>> but with a ".ga" (for Google Analytics) as an additional suffix so that
>> an institution wanting to use them has to rename them before doing the
>> 'install'? These templates would have the Google Analytics tracking code
>> embedded in them (that is generic, and would work for anyone), and woudl
>> otherwise be identical to the current OpenSAML ones.
> 
> I would not be in favor of having anything that uses third party cookies
> or web tracking included in the code base. If somebody wants to do this,
> they can download any example files you want to post and do it easily
> enough. I think that's less confusing then renaming the files anyway.
> 
> I *am* willing to add a stubbed/empty #include to the templates in the jar
> file if it turns out that it's possible to include something from the
> classpath that lives in WEB-INF.

I finally got all the pieces in place to test this. And one can #include a file successfully, where the path is relative to the 'WEB-INF/classes' directory. I had gone ahead and copied my version of the 4 templates into the 'WEB-INF/classes/templates' directory, but each one had the same #include to include a file with a single line containing the Google Analytics key. If I put '#include ( "GAkey.vm" )' into the template, then the file GAkey.vm is expected to be in the 'WEB-INF/classes' directory.

Since one is going to have to copy 4 or 5 files into either the 'WEB-INF/classes' or 'WEB-INF/classes/templates' directory anyways, I don't know if including a stubbed file include in the distribution templates really makes anything easier. You don't want to put the exact same GA javascript in each of the 4 templates because it's nice to have a different string for the "Action" parameter of the event being tracked in each of those templates (e.g. saml2 post, saml1 post). So you'd need to have each template include a different stubbed file, and one would still need 4/5 files. Unless you wanted to add a Velocity "set" in also. So you'd need to add something like

<head>
#set( $samlResponseType = "saml2-post-binding" )
#parse GAjavascript.txt
</head>

in each template, varying the samlResponseType string in each. (Unless Velocity can access the filename of the file containing it, but I haven't found anything about accessing environment variables.) Then one could get by with replacing a single stubbed file containing the full set of javascript, which would itself reference that $samlResponseType. (Note I switched to '#parse rather than #include because one would need Velocity to evaluate the $samlResponseType in the file that is read in.)

> Then they would just add the bits to that
> file so that instead of including nothing, it includes whatever they want
> it to include.
> 

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.