Alternative IdP Working Group

["Chalmers, Alex" <>]

As an ADFS 2.0 implementer with InCommon in 2011, either of these approaches 
would have been helpful.  We had some major issues in the beginning, but 
three 
years on I think we are in relatively good shape.  A bit of guidance and good 
documentation around implementing to InCommon best practices would have done 
wonders to mitigate our teething issues.

In any case, I think there is a middle ground that could be available, 
especially with products like ADFS.  A prepackaged configuration, with 
documentation, could be developed that would provide a basic bootstrap 
configuration with InCommon and release a basic set of attributes.  Beyond 
this basic setup and validation, some sort of facilitator could be utilized 
for customization of attribute release policies or provide guidance in 
handling issues like changing usernames, etc.  I think this approach could 
generally work for largely configurable products, but more customized or 
solutions needing custom code could be problematic.

For ADFS, specifically, I could see this approach packaging up a metadata 
preparser (FEMMA, pysFEMMA, or an alternative) along with a common set of 
attribute rules and some implementation guidance, with the requisite 
implementation caveats, as an "InCommon ADFS Booster Pack".  A consultant or 
facilitator could then use this as a minimum required configuration to base 
additional implementation from.

I just joined the list today, so I'm catching up on the group's previous 
work, 
but I would be happy to share Ball State's experience integrating with ADFS 
to 
anyone interested.

-abc


  Alex B Chalmers
  Associate Director, Enterprise Technology and Information Security Services
  Enterprise Systems and Infrastructure
  Ball State University

  

  765.285.3047 o
  765.744.6439 m



-----Original Message-----
From: 

[mailto:]
 On Behalf Of Janemarie Duh
Sent: Monday, August 25, 2014 7:06 PM
To: 

Subject: Re: other strategies that still involve the open source IdP stacks

On 08/20/2014 12:40 PM, Scott Koranda wrote:
> Hello,
>
> In the grid that we have constructed so far both Shibboleth and
> SimpleSAMLPhP (local) are single rows, assuming that the operator is
> going to download, configure, and deploy in the usual way that the
> larger organizations have done in the past.
>
> For each of those two software stacks I can envision two more strategies:
>
> - taking each software stack and re-packaging it to include InCommon
> specific boilerplate configuration as well as documentation
>
> - pairing a small organization with an "InCommon approved"
> facillitator/consultant to help guide the organization from initial
> contact up through on-going operations. The facilitator/consultant
> relationship would be "light weight" in that a small organization
> would not have to go through the usual proposal/SOW/contract
> negotiation. Perhaps InCommon has an arrangement to offer X hours of
> "free" consulting to small organizations, or maybe the consultant has
> a simple "pay by the hour with a credit card" offering.
>
> The two strategies above could also be extended for ADFS to some extent.
>
> Thoughts?
>
> Are these types of strategies within scope for this group?

Scott,

Your second idea is intriguing.

I was going to add your first strategy to the grid but something gave me
pause. The task of the group is to recommend solutions for IdPs that are
available now to be implemented. So we're not looking ahead to future
solutions.

That said, perhaps we add a section to the final report looking ahead to what
solutions could be. We could then make a recommendation that someone in
InCommon investigate a solution that ties your two ideas together, i.e., a
Shib-in-the-Box solution that a consultant aids in deploying.

Do I hear a moo?

             Janemarie



>
> Thanks,
>
> Scott
>


--
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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature