Shibboleth Developers

["David L. Wasley" <>]

I suppose that could work but does require signed cookies (in the 
good old days I'd edit mine appropriately).

If we say the basic requirement is to identify the workstation, not 
the individual at it, then the choices would seem to be (1) where it 
is, mapped to what it is, (2) something it has intrinsically (e.g. 
MAC address, cpu S/N), or (3) something that is placed on it (signed 
cookie, certificate, special version of the browser, etc.).  The 
first just seemed easiest to manage.  The second would be pretty 
easy, requiring registration of some sort.  The third could work too 
but seems a little less secure to me (but maybe secure enough).

Is there a requirement that a particularly privileged user be able to 
assert their own identity at such a workstation?

As for network topology changes, I really like the idea (some day) of 
requiring authenticated DHCP for all network attachments.  That way 
you get a log of who is at each machine as well as the MAC address, 
IP address, and potentially the switch port.  The same certificate 
that would support the DHCP authentication could work for the campus 
ISO/SSO.

        David
-----
At 10:19 AM -0500 on 2/8/02, Tom Dopirak wrote:

> David ,
>
> I think you are saying that the HS and Webiso should have no real part
> in determining whether an Origin is a kiosk kind of machine and requires
> no user authentication and that either an IP address or a certificate
> are sufficient in cooperation with the AA and a directory to give the
> machine whatever entitlements are necessary.
>
> Is there another choice? Ip address based solutions work but have an
> inherent dependency  on tracking rearrangements of the network topology
> are influenced by DHCP, NAT etc. I guess I like the certificate model a
> little better but this of course depends upon having that kind
> infrastructure in place.
>
> The U Wash folks use a technique where they pre-configure their browsers
> so that something is added to the user_agent CGI variable ( U Wash folks
> please chip in). This allows their Webiso service to login in a way that
> customizes the  authentication cookies for Kiosk use. This might be
> further extended to denote anonymous login.
>
> I can also imagine some technique where a long term cookie gets set
> because an admin authenticates to a website that scopes some cookie
> broadly enough .
>
> Tom
>
>
>
>
>
> >  -----Original Message-----
> >  From: David L. Wasley 
> > [mailto:]
> >  Sent: Thursday, February 07, 2002 1:11 AM
> >  To: Tom Dopirak; 'Scott Cantor'; 'Shibboleth Design Team'
> >  Subject: Re: Public terminals , libraries , kiosks
> >
> >
> >  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-sh
> >  ib-design-+
> >  >For list utilities, archives, subscribe, unsubscribe, etc.
> >  please visit
> >  >the ListProc web interface at
> >  >
> >  >     http://archives.internet2.edu/
> >  >
> >  >------------------------------------------------------mace-sh
> >  ib-design-
> >  >-

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

   http://archives.internet2.edu/

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