Shibboleth implementation for an application

[Rank, Mark]

+1 and nominate for carving in stone...

--------------------------------------------------
Mark Rank
Project Manager - Identity & Access Mgt
UCSF Information Technology Services (ITS)
email: mark.rank at ucsf.edu
phn:414-331-1476
--------------------------------------------------
________________________________
From: users-bounces at shibboleth.net [users-bounces at shibboleth.net] on behalf of David Bantz [dabantz at alaska.edu]
Sent: Tuesday, September 03, 2013 11:28 AM
To: Shib Users
Subject: Re: Shibboleth implementation for an application


On Mon, 2 Sep 2013, at 08:52 , "Cantor, Scott" <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:

The application needs to determine the appropriate set of
attributes it needs to obtain from IdPs to operate, and then it needs to
enforce a policy based on them about who gets access.

You also need a strategy for provisioning and dealing with the way new
users are added, because unlike LDAP, you don't get to assume that the
universe is that LDAP server. Federation doesn't work like that. The set
of potential users is essentially infinite and not accessible to the app
at any time for examination, and there will almost always be users who can
authenticate to the IdP but should not have access to the app. You cannot
punt that decision to the IdP unless you require some kind of entitlement
string be provided by the IdP to indicate that some policy has been
enforced at the IdP.

Great < 150 word summary of critical point that too many app administrators haven't internalized.

David Bantz
U Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130903/7172997d/attachment.html