Alternative IdP Working Group

[David Walker <>]

I've always viewed this table as a deployment table.  The columns that,
I believe, have been associated with "implementation" I associated with
"capabilities."  The fact that the same text may appear for some columns
of multiple rows didn't bother me, as it's not a very big table.  In the
end, I think we'll want to present our findings as a set of deployment
options (which do include software) without making the reader jump
around too much.

That said, I'm OK if there's general support for creating an
"implementation" table (although perhaps "software" would be a better
name for it?).  We probably don't want to go too deeply, though, into a
comparative evaluation among the software options, independent of the
deployment strategies we've identified.  That could really be a rat hole
for our effort and probably not particularly useful for our target
audience who aren't going to want to do a lot of improvisation on what
comes "out of the box."

Regarding outsourced strategies, I had originally figured that we'd have
multiple rows for similar outsourced services from multiple providers. 
Perhaps for now it makes sense to describe a particular outsourced
offering (even if hypothetical), then we can approach vendors for
variants of that row, as we feel is appropriate.

Regarding Mark Scheible's comments about the "applicable environments"
column, I was thinking of that as being something like "AD-centric" for
ADFS, or "Google-centric" for a GAE gateway, which is certainly one of
the reasons to be considered in making a selection, but not the only
one.  I do like the suggestion of a "risks" column to balance
"benefits."  Maybe just "pros" and "cons" would be even better?

David


On 08/27/2014 08:34 AM, Mark Beadles wrote:
>> This is important but probably not something
>> that is easily captured in a table.
> Unfortunately correct. In practical terms this is something that is going 
> to differ from vendor to vendor, and not really from deployment type to 
> deployment type. The reason this stuck out in my mind is just a sore point: 
> there have been cases we've found where a vendor is providing 
> managed/outsourced Shibboleth, but their ability to provide complete 
> configuration/operation is not as good as if a dedicated expert internal 
> resource was configuring/operating it. 
>
> mark 
>
>> -----Original Message-----
>> From: 
>> 
>>  
>> [mailto:]
>>  On Behalf Of Tom
>> Scavo
>> Sent: Wednesday, August 27, 2014 11:24 AM
>> To: Mark Beadles
>> Cc: Mark Scheible; Tom Scavo; Janemarie Duh; 
>> 
>> Subject: Re: implementation vs deployment criteria
>>
>> On Wed, Aug 27, 2014 at 10:44 AM, Mark Beadles 
>> <>
>>  wrote:
>>> ... in outsourced environments there is a dependency on which functions 
>>> the
>> outsourced vendor is choosing to implement in its standard package. E.g. 
>> Shib
>> itself supports, ECP but to work it must be properly enabled/configured by 
>> the
>> third party vendor; or if multiple authentication contexts are desired, 
>> then the
>> vendor must install and support MCP.
>>
>> The same is true of local deployments of Shibboleth. Indeed, relatively few
>> Shibboleth deployments (local or otherwise) support ECP or the MCB, so the
>> point is moot, I think.
>>
>>> So there is some dependency on whether Shib is deployed internally or at a
>> vendor, although the details will differ from vendor to vendor.
>>
>> In terms of ECP, which is a built-in function of Shibboleth, I'm just not 
>> seeing a
>> distinction. MCB is another story since MCB is an add-on and vendors are 
>> loath
>> to extend the out-of-box solution for obvious reasons. There are other
>> important Shibboleth add-ons we need to consider as well, including SHA-2
>> capability and the ability to leverage MDRPI extension elements in 
>> metadata.
>>
>> That said, I get what you're saying. The Internet2 Google Gateway is a 
>> vendor
>> deployed instance of simpleSAMLphp with numerous enhancements not
>> available from SSP out-of-the-box. This is important but probably not 
>> something
>> that is easily captured in a table.
>>
>> Tom