Canarie Installer suitability for Shib "quick start"?
Marlena Merrin-Erdos
marlena.erdos at gmail.com
Tue Feb 28 16:21:11 EST 2017
Hi Rod (and Shib-dev),
First off, thank you for your note.
Before I launch into answering your specific points, I want to give some
thoughts about this Quick Start Deployer's Guide project. That will
provide some useful context (I believe).
Our big problems (IMO) are:
- deciding on "audience": what type of user and institution are we
targeting; who are we consciously leaving out
- deciding what the installer does that might make an audience member's
life easier.
- differentiating what's a Quick Start Guide, and what's in a System
Administration Guide
I'm not set in stone on "audience" and that really is the key factor.
I'm not the decider though. It's "TIER" in the form of Steve Zoppi and
whomever he believes the other "deciders" are.
That said, I can offer recommendations to him -- once I have them! :-)
That's where the dev list comes in (if folks weigh in).
**
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.
This is a great point -- but not a damning one given that TIER is funding
the work. A "Quick Start Guide for TIER Institutions" would likely suit
TIER just fine. This is especially so given that TIER is expecting an
influx of community colleges and K-12 schools who will want IdPs (according
to Paul Caskey).
Note: There's a goal for TIER beyond improving a newbie's Shib installation
experience. And that is having a comprehensive set of documents for its
product set. These are items that demonstrate in important way the
'goodness' of TIER's work to the set of funders that made TIER possible
(and may fund parts of TIER further).
This aspect of "what will help TIER" is on par (for me) with "what will
help the user."
**
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.
This is also an excellent point. I have two responses:
- Most of this ongoing maintenance of the IdP belongs in a System
Administration Guide, not a Deployment Guide (IMO). (The "Deployer's Guide"
really should be called "Installer's Guide" to avoid confusion due to the
larger meaning of "deploy" vs"install." I might advocate for this.)
- If a school brings up an IdP and demonstrates its value --- say by
allowing for a connection to HathiTrust (a library resource) -- then the
school might (might) be able to get funds to support "doing the IdP right"
in an ongoing way
**
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.
Scott and I proposed a "Concepts & Basics" mini-project to Steve Zoppi, as
well as two other Shib doc projects.
Steve told me he is working on getting funding for these projects, but that
he doesn't have it now. (Just in case anyone is wondering: I am unwilling
to put in "Concepts & Basics" info into the Deployer's Guide (apart from a
couple of introductory paragraphs of course).)
Setve does have funding for some form of Deployer's Guide (which really
should be called "Installer's" Guide (IMO) to better separate out
"installation" from "on-going administration.")
I appreciate getting information and pushback about "what should we be
writing." At this point though, I believe that we have buy-in and
resources (including but not limited to funding) for only a Quick Start
Installation Guide.
Given that, the question (it seems to me) is "what is the installation
process that goes along with the Quick Start Installation Guide"?
**
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.
I myself am not set up to be able to evaluate any installer. (I'm an
independent consultant, not affiliated with a higher-ed institution. I'd
be happy to get set up though if there's a way to do that given my piddling
Windows laptops.))
Paul Caskey might be able to spend cycles on such an evaluation though.
Paul?
**
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?
The installer admin probably hasn't. But, if the IdP is brought up and is
shown to be useful, that's a very helpful thing for getting funding to get
the right people to go through the thought process.
If I didn't see this as not only a real, but likely possibility (for many
schools), I would be highly bothered by "just" providing a QI installer.
**
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.
I'd put this in a System Administration Guide. That said, we (the dev
group plus me) can debate what's in and what's out -- and I'll take back my
resultant thoughts to Steve Zoppi (who will decide).
If we do have a QI Installer, and hence a very short doc that's actually on
"installation," TIER might fund me adding in "system admin" topics to the
QI Guide (maybe), or fund a "Quick System Administration Guide."
**
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?
Yes. Agreed. Deciding on the audience is key.
**
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.
I'd definitely like to see Rhys's materials -- if he is willing to share
them.
**
If I didn't address a point that needs to be addressed, let me know, OK?
I much appreciate your note!
Thx,
Marlena
On Mon, Feb 27, 2017 at 9:00 AM, Rod Widdowson <rdw at steadingsoftware.com>
wrote:
> 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/
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
--
617-216-6563 (cell via Google Voice) or 857-308-6986 (direct cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170228/06db4fd3/attachment-0001.html>
More information about the dev
mailing list