Alternative IdP Working Group

[Mark Beadles <>]

I agree with the overall notion of deployment vs. implementation but I think 
we need to be careful about:

> Example: Shibboleth supports automated metadata refresh
> (implementation criteria #1). It doesn't matter if you deploy
> Shibboleth locally, or outsource the Shibboleth deployment to a
> vendor, or deploy Shibboleth in AWS. Shibboleth is Shibboleth, and it
> supports automated metadata refresh.

For "core" Shib functionality this is true, but 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. So there is some dependency on whether Shib is deployed 
internally or at a vendor, although the details will differ from vendor to 
vendor. 

mark



From: 

 
[mailto:]
 On Behalf Of Mark Scheible
Sent: Tuesday, August 26, 2014 8:26 AM
To: Tom Scavo
Cc: Janemarie Duh; 

Subject: Re: implementation vs deployment criteria

I like the idea of a deployment table.  I see the last 5 columns being there, 
plus (and maybe in both tables) we need a "Risks" column to balance the 
Benefits column.  Also, "Applicable Environments" works technically, but its 
more about describing the institution's "Reason" for deploying a specific 
solution.  Environment sounds too static, and it's likely that a choice is 
made due to current circumstances - e.g. Loss of key technical resources, 
budget cuts, preferred vendor under statewide contract, etc.

Mark



Mark A. Scheible
Sr. Lead IAM Solutions Architect
MCNC, Research Triangle Park, NC
Office: (919) 248-1997
Cell: (919) 609-8595
Fax: (919) 248-8419

On Tue, Aug 26, 2014 at 7:57 AM, Tom Scavo 
<>
 wrote:
On Mon, Aug 25, 2014 at 7:25 PM, Janemarie Duh 
<>
 wrote:
>
>      Could you please define deployment vs. implementation?
Sure, I'll do that by example. See this wiki page:
https://spaces.internet2.edu/x/EA3kAg

There are a bunch of implementation criteria listed on that page. Each
is constant with respect to deployment so it doesn't make sense to
include implementation details across deployment strategies. It's
redundant.

Example: Shibboleth supports automated metadata refresh
(implementation criteria #1). It doesn't matter if you deploy
Shibboleth locally, or outsource the Shibboleth deployment to a
vendor, or deploy Shibboleth in AWS. Shibboleth is Shibboleth, and it
supports automated metadata refresh.

> Would the
> deployment details be less technical and more with fitting a solution
> into an existing, or non-existent, IdMS?
A deployment strategy describes HOW you use the federating software,
not the implementation details of WHAT the software can do.

Example: simpleSAMLphp can be deployed as an ordinary IdP in a typical
campus scenario (base case), or as a social-to-SAML gateway, or as a
SAML-to-SAML gateway. All are listed as a deployment strategy in our
table. The fact that the SSP software signs assertions using either
SHA-1 or SHA-2 digest algorithm on a per-SP basis (implementation
criteria #4) is a given across all those deployment scenarios.

> That might lead, then, to
> adding columns describing what each strategy would require in a design
> for a supporting IdMS in order to be deployed.
No, we need two tables. The first table describes each implementation.
It has three rows, one each for Shibboleth, simpleSAMLphp, and AD FS.
It has 10 columns, one for each of the implementation criteria listed
on the above wiki page (or whatever set of implementation details we
want to study).

The second table describes each deployment. It has the same rows as
the current table. It has columns corresponding to the last five
columns in the current table (or whatever set of deployment criteria
we decide to study).

Does this help?

Tom