Alternative IdP Working Group

[Chris Phillips <>]

Hi Steve,

You almost have remembered it right, but not quite ;)

What we have been doing is building an open source tool that automates the
installation of the IdP for either eduroam and/or Shibboleth. They can be
installed together or separately.
We started awhile ago and recently posted our general release and will be
formally announcing in the next while:

http://ow.ly/CaBMW 



The goal with this is to lower the barrier to deploy an IdP dramatically
from days/weeks to a few hours.

We wrestled with many of the aspects that the columns in that table call
out as a precursor to the work on the IdP-Installer. It's what set us on
this journey to simplify things.

Many institutions mid to small size are just too strapped for resources
and available skills to be as sophisticated deployers as larger
institutions.  That said, we are hearing that larger institutions want to
use the installer for their IdP updates as the working baseline to do
their upgrade to a new machine. They too are hit with a skills retention
problem -- people are just naturally transitioning through their roles and
the tribal knowledge sometimes moves with them so the larger institutions
see this tool to at least cover the hard parts without diluting the
capabilities of the tools themselves.


CANARIE doesn't host any IdPs other than our own IdP and a CAF Guest IdP
(which is not in our metadata).
 We do see an opportunity  for someone to take the IdP-Installer tool that
we have and automate installs to the level that they can be easily be
hosted by someone.  Hosting IdPs is a deeper topic and if that's a
direction to go in on the list, let's carve that off to a separate thread.
 I'm available off list for conversations in this space as well.  The
IdP-Installer is practically 'headless' so it can be run as a post-install
process for a machine.. Lots of things to chew on..

Readers on this thread after a bit of looking will see that we have
implemented the IdP Installer in such a fashion as to allow other
federations to extend it.  We've worked closely with SWAMID who has also
leveraged the same shared code base for the installer for their automated
tool. We have had this tool in beta for 6 months now and have some
institutions live and in the midst of going live with it here in Canada.

You can see our joint presentation from TNC2014 in Dublin about this:

https://tnc2014.terena.org/core/presentation/57

( it was recorded as well and can be found at tnc2014.terena.org under
'simplifying federation deployment')


So what could happen next?

Well, in addition to the above options, if there is desire for an
'inCommon build of the IdP-Installer' its very easy to commence that
effort.  The work is entirely on Github and can be forked from a master
repository that both CAF and SWAMID forked ours from and we promote our
work back into.  You get the benefit from all the work and can, in return,
promote your innovations back into the core. (I need to push our latest
efforts into it right now BTW)
If someone is interested in this, I'm more than happy to have the
conversation about how it can be done and how you(your
institution/federation/organization) can benefit from the work.

As for the alternate IdP WG, if this option wants to be considered as a
distinct line on the spreadsheet to be compared to the others, that would
be a very interesting thing too.  I had not offered it yet until we
reached our current stage and would be glad to fill in the elements as
needed if the group wants to consider it. Having an inCommon champion for
this would be pivotal to see it be sustainable and do well..


Chris.

P.s. BTW, that meeting in SF last year was a key moment for this work. I
was able to spend half a day heads down with my SWAMID counterpart and lay
the foundation for this highly collaborative work. Without these
identity/working group focused meetings it would have taken much longer to
get where we are. On that note, I look forward to seeing everyone in
Indianapolis this year :)




On 14-10-01 12:03 PM, "Steven Carmody" 
<>
 wrote:

>On 9/30/14 9:29 AM, Chris Phillips wrote:
>> Been lurking on here for awhile, apologies for not being on the calls..
>
>Chris ...
>
>I seem to remember that a year ago, at the REFEDS meeting in SF, you
>described a service that Canarie was offering to member campuses where
>the Federation would operate the infrastructure for an IDP and eduROAM?
>
>I'm sure I'm mis-remembering that -- but, would it be worthwhile for us
>to include a row that describes a service like that ? Is it sufficiently
>different from the other rows that it would be worthwhile calling it out
>as a separate option ? I know IC doesn't currently offer anything like
>this. But, if this approach is providing value to your members, then I
>think we should describe it.
>
>>
>> Maybe they could go, but from a business case (e.g. I need Multfactor
>>for
>> service X) it illustrates the can of worms exists instead of hide it
>>under
>> the carpet or it being absent during a comparative analysis.
>>
>> When assessing any path to take, I would highlight or call out that
>> certain things are make or break decision areas and these may be them.
>>The
>> features exist for a reason and if that is unique to that space, it may
>>be
>> the sole reason for someone to adopt that implementation.
>>
>> If you take them out of the table for readability, no problem, but maybe
>> create a separate section for
>> Unique features' and give appropriate airtime compared to the larger
>>table?
>>
>>
>>
>> C.
>>
>>
>> On 14-09-30 9:16 AM, "Tom Scavo" 
>> <>
>>  wrote:
>>
>>> On Sat, Sep 27, 2014 at 3:38 PM, David Walker 
>>> <>
>>>wrote:
>>>>
>>>> I noticed a couple of columns where
>>>> we might not be completely in agreement.  Here are proposed
>>>> interpretations:
>>>>
>>>> Support for Entity Categories (R&S).  The issue here is whether the
>>>>IdP
>>>> can
>>>> be configured to release attributes automatically to any SP in a
>>>> specified
>>>> Entity Category like R&S.
>>>
>>> AFAIK, Shibboleth is the only software in the world that can leverage
>>> entity attributes at the IdP. If that's true, then there isn't much
>>> point having such a column in the table.
>>>
>>>> Support for Multiple AuthN Contexts for MFA and Assurance.  The issue
>>>>is
>>>> whether the IdP can invoke different authentication methods based on
>>>> authentication contexts specified in the SAML request (e.g., the
>>>> Multi-Context Broker).
>>>
>>> Likewise this column is a can of worms and should probably be removed.
>>> First, the MCB is add-on software, not baked in, so I'm not sure it
>>> qualifies as an illustrative example. Moreover, I'd be very surprised
>>> if ANY software can process specific RequestedAuthnContext values
>>> out-of-the-box, especially for values not defined in the SAML2
>>> Authentication Context spec.
>>>
>>> Tom
>>
>