Canarie Installer suitability for Shib "quick start"?

[Rod Widdowson]

Warning, brain dump ahead.

So, speaking with my "Shibboleth Team" hat on....

> I'm writing to get your thoughts about the Canarie Installer.   

I haven’t played with it recently, but I spoke to Chris as he wrote it and I love what it does.   I think it is a vindication of the "property driven installation" mechanism we started in V3 and I'm looking forward to adding fuller support for it in V4.

> I'm also happy to hear about other possibilities for a "quick start" installation tool.

Having authored a reasonably successful _and_ deeply flawed "quick start" installer those words strike dread into my heart.  They also have a particular meaning to me and so I'm leery of them ; but I do not think that (what I think of as) a quick installer is a necessary part of a quick start developers guide.  Or even a good one.  

As soon as you build a quick start installer you have cut yourself off from the majority of our (Shibboleth's) users.  Significantly, you have also tied them to a platform.  Also you have tied them to particular federation's operating principals and you have probably tied them to a security model, you may even have tied them to a legal regime.  In addition, if you give people an artefact they will probably declare victory with no knowledge they'll not have a plan for upgrading Java, or the container, or the IdP.  So you now have to own that problem as well as an ongoing cost.

Also, I'd like to understand where a TIER QI ties in to the Docker thingy that I had heard that they had done....

On the other hand, good documentation always has some relevance to all of our customers.   That’s why I think that for the project and its maintainability "getting started" _documentation_ is far more valuable than a bundled installer.

Quick Start Installers have a great place - but as a federation tool, deeply integrated into their support mechanism, trust framework and operating procedures.  Federations also have the ability to meet the recurring costs of maintaining the installer.  And our task as Shib developers should be to continue to drive down the cost of writing & maintaining Federation installers, beyond that I cannot really comment.

But I will... So if, notwithstanding what I say above you really do want other ideas for installers to look at, you should also look at the windows installer. It would not be hugely difficult to Transform it (the way that the old OpenAFS windows installers did[1]) to fit into a specific Federation's operating principals - I designed it with that in mind.  It can already do AuthZ (although I hate that bit) so all it is missing is canned metadata and common attributes from AD.  Write the Transform to massage the MSI, plugging in your own properties and a couple of XML files, slam a new skin on it, sign it, and you're done.  

I think that the NZ Federation also has a layered installer which would be worth looking at.  

When it comes to it you are writing a hand full of files and calling the IdP installer appropriately, the difficulty lies in asking the right questions and biting off the maintenance.

To take a step back and consider a Quick Start Deployment Guide.

> Someone will no doubt ask "what's in a 'quick start' deployment?  Well, that's not set in stone, but here are some items we can
> consider:
> • Basical ability to bring up the IdP (ideally with few steps on the newbie's part)
> • Connect to the newbie's vanilla LDAP (for attributes for sure, and maybe also authN), preferably securely
> • Test basic attr resolution and filtering, possibly using a canned account for authN
> • Bring in InC metadata (ideally with few steps on the newbie's part)

S/InC/Federation's/ 

This seems pretty reasonable.  

In passing I'll note that to a certain degree LDAP AuthN is easier than LDAP attributes because you can get a lot done purely with properties.  Further, AuthN is a binary thing.  Attributes require thinking about - what are you releasing?  Why?  To Who?  What are the legal implications?  Again this gets me back to why a QI installer is a worrisome thing.  Has the user gone through the thought processes?  Is it OK to encourage them to do things with real legal ramifications on the click of a button?  

But when it comes to it, it's all about properties and XML files.  Documentation tells what properties to change and why and how to write the file; QI supplies the file and sets the properties based on user input and federation policy.  Think corny analogies about hungry men and fishing.

Anyway the biggest missing bullet is continued maintenance.  Bringing up an IdP quickly is great, but it has to be just as easy (and preferably easier) to respond to security alerts.  You need to know where to go for the security alerts, you need to understand the technical and legal issues about Java distribution (aka you have to download and update it from Oracle) and so the list goes on.

Widening it slightly, although I said (and maintain) that good documentation is of value to everyone you must have a target audience.  Who are they?  What do they know? What do they _need_ to know?  What will they know at the end that they didn't at the start?

There is I guess a mid-place between an installer and pure documentation and that is a "how to" guide, possibly using canned examples - at the end the user can go away and do it again, but for real.  This is where the various Federations classes can provide help and input and material.  I cannot speak too highly about the classes Rhys put together when the UK Federation was onboarding a vast number of IdPs (which seems to be the agenda here?).  He'll be lurking on the list I guess - or I can put you in touch off list.

Of course a "how to" also requires maintenance, more than documentation, less than a QI... 

I hope there is some value in this incoherence....

Rod

[1] http://slideplayer.com/slide/5735313/