Canarie Installer suitability for Shib "quick start"?

[Cantor, Scott]

On 3/1/17, 7:03 PM, "dev on behalf of Marlena Merrin-Erdos" <dev-bounces at shibboleth.net on behalf of marlena.erdos at gmail.com> wrote:

> 1) There's absolutely a resource from TIER!   Paul Caskey. 

Ok. That hasn't been part of any conversation about what I assumed was a pure documentation task to this point. I think it is a risk to over-complicate that goal with software changes or new work. 

> How much of his time is available is not decided.  If there are specific tasks he could do that improve the install/initial
> config/test-along-the-way experience, he could estimate the hours, and then Steve Z and Ann West could decide on
> whether he can go forward.

We don't have some grand plan for what needs to be done that's just waiting on the resources. The analysis of the work to do is time consuming work itself.

When I decide to tackle something on our list, that's when I do the thinking about it. Until that happens, I don't really have the vaguest idea what any of the work might take or how it might take form. I can usually say "big", "medium", or "small", or identify gating factors or external dependencies, but that's about it.
 
> Given this, what can "we" do that improves the install/initial config/test-along-the-way experience?

It hadn't even occurred to me to think about the question because there were no resources being offered to do any of it. If I have some idea of the kind of schedule and resources involved, I imagine I can spend some time next week thinking about some of the possibilities. But by and large I think this is all gravy, and mostly just complicates this proposal vs. helping it succeed.

> 2) You seemed to agree to the "success factors" I put forth in the Success Factors 

Long term, yes. I did not mean to imply that nothing could be done re: documentation without those things happening. I meant that they were useful suggestions to the project to work on over time. I assumed that any new documentation would leverage what exists, and be improved over time to take advantage of new things as they emerge, with one of the open questions being exactly who would be expected to maintain it so that happens when it needs to. This is why it can't be a static deliverable.
 
> I'm pretty set on having the "Success Factors" above met (e.g. "test ldap" capability) so that may be a point of contention,
> but let's see!

Given a bit of mocked up metadata, it is possible to write very simple instructions for how to test both authentication and (via the command line tool) the attribute layer now with no additional changes.

The reason we haven't ever included that kind of metadata out of the box is that leaving it in place is a data exposure risk, but I think we may look at including it with a dynamically generated validUntil of maybe a week or something like that, so that people get something they can test easily right away, but it stops working after it's not needed.

Since TIER is going to be including its own default configuration of the IdP anyway, even if it just slaps that on top of a standard installation, that's the kind of thing it can include with no software changes that new documentation could take advantage of.

-- Scott