Alternative IdP Working Group

[Mark Scheible <>]

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