Alternative IdP Working Group

[Mark Beadles <>]

> 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