<div dir="ltr"><div>Hi Rod (and Shib-dev),<br><br></div><div>First off, thank you for your note.<br><br></div>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).<br><br>Our big problems (IMO) are:<br><div><ul><li>deciding on "audience": what type of user and institution are we targeting; who are we consciously leaving out<br></li><li>deciding what the installer does that might make an audience member's life easier.</li><li>differentiating what's a
Quick Start Guide, and what's in a System Administration Guide</li></ul>I'm not set in stone on "audience" and that really is the key factor. <br><br></div><div>I'm not the decider though. It's "TIER" in the form of Steve Zoppi and whomever he believes the other "deciders" are. <br></div><div><br></div>That said, I can offer recommendations to him -- once I have them! :-) That's where the dev list comes in (if folks weigh in).<br><br>**<br><div style="margin-left:40px">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. <br></div><div><div><div class="gmail_extra"><br><div>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).<br><br></div><div>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). <br><br></div>This aspect of "what will help TIER" is on par (for me) with "what will help the user."<br><br>**<br><div style="margin-left:40px">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.<br><br></div>This is also an excellent point. I have two responses:<br></div><div class="gmail_extra"><ul><li>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.)</li></ul></div><div class="gmail_extra"><ul><li>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</li></ul><p>**<br></p><p style="margin-left:40px">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.</p><br>Scott and I proposed a "Concepts & Basics" mini-project to Steve Zoppi, as well as two other Shib doc projects.<br><br></div><div class="gmail_extra">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).)<br></div><div class="gmail_extra"><br>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.")<br><br></div><div class="gmail_extra">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. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Given that, the question (it seems to me) is "what is the installation process that goes along with the Quick Start Installation Guide"?<br><br>**<br><br><div style="margin-left:40px">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.<br></div>
<br><div style="margin-left:40px">
I think that the NZ Federation also has a layered installer which would be worth looking at.<br><br></div>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.)) <br><br></div><div class="gmail_extra">Paul Caskey might be able to spend cycles on such an evaluation though. Paul?<br><br></div><div class="gmail_extra">**<br><br><div style="margin-left:40px">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?</div><div><br>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.<br><br></div>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.<br><br>**<br><br><div style="margin-left:40px">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. <br></div><br>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). <br><br>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."<br><br>**<br><div style="margin-left:40px">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?<br><br></div>Yes. Agreed. Deciding on the audience is key.<br><br>**<br><br><div style="margin-left:40px">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.<br><br></div>I'd definitely like to see Rhys's materials -- if he is willing to share them. <br><br></div><div class="gmail_extra">**<br></div><div class="gmail_extra">If I didn't address a point that needs to be addressed, let me know, OK?<br><br></div><div class="gmail_extra">I much appreciate your note!<br><br></div><div class="gmail_extra">Thx,<br></div><div class="gmail_extra">Marlena<br></div><div class="gmail_extra"><br>
</div><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 27, 2017 at 9:00 AM, Rod Widdowson <span dir="ltr"><<a href="mailto:rdw@steadingsoftware.com" target="_blank">rdw@steadingsoftware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Warning, brain dump ahead.<br>
<br>
So, speaking with my "Shibboleth Team" hat on....<br>
<br>
> I'm writing to get your thoughts about the Canarie Installer.<br>
<br>
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.<br>
<br>
> I'm also happy to hear about other possibilities for a "quick start" installation tool.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Also, I'd like to understand where a TIER QI ties in to the Docker thingy that I had heard that they had done....<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I think that the NZ Federation also has a layered installer which would be worth looking at.<br>
<br>
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.<br>
<br>
To take a step back and consider a Quick Start Deployment Guide.<br>
<br>
> 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<br>
> consider:<br>
> • Basical ability to bring up the IdP (ideally with few steps on the newbie's part)<br>
> • Connect to the newbie's vanilla LDAP (for attributes for sure, and maybe also authN), preferably securely<br>
> • Test basic attr resolution and filtering, possibly using a canned account for authN<br>
> • Bring in InC metadata (ideally with few steps on the newbie's part)<br>
<br>
S/InC/Federation's/<br>
<br>
This seems pretty reasonable.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Of course a "how to" also requires maintenance, more than documentation, less than a QI...<br>
<br>
I hope there is some value in this incoherence....<br>
<br>
Rod<br>
<br>
[1] <a href="http://slideplayer.com/slide/5735313/" rel="noreferrer" target="_blank">http://slideplayer.com/slide/<wbr>5735313/</a><br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a></font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">617-216-6563 (cell via Google Voice) or 857-308-6986 (direct cell)<br></div></div></div></div>
</div></div></div></div>