[Fim4l] Stanfords statement

Nick Roy nroy at internet2.edu
Thu Mar 28 17:01:23 CET 2019



On 28 Mar 2019, at 7:46, Peter Gietz wrote:

> Since no one else responds, and since I have some time now, I will,  but only on the IP auth subject, ePTID has been discussed a lot here and on the REFEDS list and we will find a language that quotes the RA21 recommendation and that argues that there may be better alternatives to it, which will need software changes on the SP side.

It should only take configuration changes, not changes to the federating software itself, but I agree, it is important to discuss eduPersonTargetedID, since it has some major security problems. The OASIS Security Services Technical Committee (SSTC) has adopted the new SAML-level, cross-sector subject identifiers [1], which are intentionally aligned with similar constructs in the OAuth space. There are two identifiers, subject-id (analogous to eduPersonUniqueID) and pairwise-id (a case-insensitive privacy-preserving pairwise identifier).

Best,

Nick

[1] http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html

>
> As to IP based authentication:
>
> Am 20.03.2019 um 20:53 schrieb Peter Schober:
>> *
> [...]
>> Some other things worth mentioning:
>>
>> Strategically I wouldn't want to be advocating for a regime change
>> from IP-based auth to FIM (in case anyone assumed that), simply
>> because the UX with IP-based auth when the subject is
>> on-campus/on-premise is unsurpassed and can never be matched by FIM.
>> (For off-campus/off-site it's more of the reverse, sadly, and so we
>> want both, IMO.)
>> FWIW, I know of one local (and not generalisable) use-case where the
>> publisher tried to get rid of any and all IP-based access and argued
>> this with fulfilling the academic institutions' own long-stanading
>> requests for SAML support. (Basically: "Here's the SAML support you
>> asked for for the last 10 years. Now it's the only access method. I
>> hope you're happy.")
>> I don't know where this group intends to take things but I'd agree
>> that there's a certain danger in asking for e.g. SAML support and then
>> losing IP-based access in the process. Though the above is the sole
>> exception to a vast amount of e-resource providers that just added
>> SAML to the existing methods available instead of replaced existing
>> ones that had (some) desirable properties.
>> (And of course managing "authorised" IP ranges is a drag, esp if done
>> in manual out-of-band workflows. Not sure it's worth investing effort
>> into making that more automated or scale better in the general case,
>> though.)
> You read well that we do want to say that eventually IP based authentication should be deprecated. I see a longer migration period, and that was the reason, why we set up pilots in AARC1 that help in the migration phase, namely a SAML infrastructure that allows for IP based authentication (based on Shibboleth). In addition one pilot allowed for easily managing IP-Ranges via a web interface with the possibility to define which attributes and values should be be sent by the IdP for which IP-range with distributed management so that any number of Institutions can participate (see [1]).
>
> What are the reasons to leave IP based authentication totally eventually?
>
> * access will more and more be through mobile and home desktops and VPN, as you correctly indicate is everything but seamless
> * more granular contracts based on attributes and not for the whole institution
> * IP spoofing
> * better identification of misbehaving users, and then only blocking this user and not the whole institution
> * Personalization features provided by SPs
> * there will be a time, when ipv4 is really dead (people are saying this since more than a decade, but eventually it will be true). And in IPv6 IP based  authentication might not be so easy any more, with IPv6 Privacy Extension, Authentication Header, etc. But I am no expert here and might be totally wrong on this last point. We haven't discussed this yet anyway.
>
> Of course the publishers have invested in SAML and now they are pushing this technology also within the RA21 activity. I guess that your one case of a publisher demanding to go for SAML only will thus become more in future.
>
>  [1] https://wiki.geant.org/display/AARC/Libraries+walk-in-user+pilot
>
> Cheers,
> Peter G.
>
>> The other issue is the fate of the eduPersonTargetedID attribute.
>> I'd hate to see anything remotely resembling Best Current Practices or
>> Recommendations, esp ones newly published, that promoted/prolonged use
>> of this historical artefact.
>> Of course we have to get from where we are (some existing support for
>> eduPersonTargetedID, some existing support for proper persistent SAML
>> 2.0 NameIDs) to SAML pairwise-id, but any language that makes
>> continued use of that legacy attribute "OK" might be actively
>> damaging.
>> (Note that any IDP already supporting ePTID should also be able to
>> support pairwise-id, it's actually much simpler. So by allowing legacy
>> bahaviour into new guidelines this would potentially undermine global
>> efforts to get away from ePTID.)
>>
>> But let's first see whether the federation community can actually
>> muster up their courage to finally "deprecate" ePTID. If that happens
>> I'm firmly counting on FIM4L not to subvert this effort.
>>
>> -peter
>> _______________________________________________
>> Fim4l mailing list
>> Fim4l at lists.daasi.de
>> http://lists.daasi.de/listinfo/fim4l
>
> -- 
>
> Peter Gietz, CEO
>
> DAASI International GmbH
> Europaplatz 3
> D-72072 Tübingen
> Germany
>
> phone: +49 7071 407109-0
> fax:   +49 7071 407109-9
> email: peter.gietz at daasi.de
> web:   www.daasi.de
>
> Sitz der Gesellschaft: Tübingen
> Registergericht: Amtsgericht Stuttgart, HRB 382175
> Geschäftsleitung: Peter Gietz
>
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20190328/8528843b/attachment.sig>


More information about the FIM4L mailing list