Shibboleth Developers

["David L. Wasley" <>]

Well, actually -- I think the issue is not what the AA says but how 
it knows what to say.  If you start with the requirement that the 
human being doesn't have to identify him or her self, then on what 
basis do you assert entitlement?

It seems to me that the most logical basis is that the workstation is 
in the library, or in the computer lab or ...   Thus my suggestion of 
using IP address, mapped into a known location.

I would create enterprise directory entries for "library computer" 
and/or "computer lab workstation", etc., and populate them with the 
attributes and/or entitlements that are deemed appropriate.  Then, 
when the HS needs to "understand who the user is" it can note the IP 
address and simply use that to index the enterprise directory.  The 
rest is automatic and quite consistent with the Shib model.

An alternative might be to place a cert on each such workstation that 
has a Subject name matching the directory entry for the generic type 
of user intended.  Again, the result is an automatic determination of 
entitlement completely consistent with the Shib model.

How can we avoid the WAYF step?  Clearly the "portal first" scenario 
would work here.  Perhaps if the WAYF used SSL to talk to the User 
and checked the cert to see if the Issuer was recognized, then it 
could go directly to the registered HS.  The rest would just work.

        David
-----
At 5:54 PM -0500 on 2/6/02, Tom Dopirak wrote:

> All,
>
>  I finally went back and read last Decembers thread on how to support
> library workstations in shibboleth. This is the situation where no user
> is available to authenticate but the actual physical location of the
> origin denotes some authentication.
>
>  David Wasley suggested that the HS figure out that the workstation is
> in the library ( perhaps by IP address) and write a special handle that
> is recognized by the AA. Thus the AA can release whatever is appropriate
> for that workstation , e.g. member of community.
>
> I am frankly uncomfortable not doing this in a more formal way,
> particularly since we need to build something and because it's a common
> problem.  I would like to come to some consensus as to how to use the
> AQHS to represent the state of something not being authenticated by a
> user authentication. I think this means specifying something additional
> in the AuthenticationStatement. I am thinking that maybe we can expand
> AuthenticationMethod  to include the notion of authenticated by
> entitlement.
>
> And this is a dumb idea because...
>
>
> Tom

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--