Alternative IdP Working Group

[Janemarie Duh <>]

Tom,

Thank you, Yes, this does help and I'd like to pursue the second table.
Mark Scheible suggested adding a Risks column. That is important since
in addition to the benefits of each solution we need to consider what
the problems may be.

FYI, I will be away on vacation beginning tomorrow (Friday) through next
Wednesday. David Walker has graciously offered to run the call on Wednesday.

If the group needs to hammer out the table designs in order to continue
with your work, go ahead during the call if need be. If it can wait
until I get back, I'll create the new grid and modify the existing one.

                Janemarie


On 08/26/2014 07: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
> 


-- 
Janemarie Duh
Identity Management Systems Architect
Information Technology Services
Lafayette College
Easton, PA 18042
610-330-5609
http://its.lafayette.edu

ITS will never ask you for your password. Never email your password to
anyone.