Shibboleth Developers

Title: SHIB design call -- (1/10/2005), 3:00 pm est, noon pst

NOTE THAT WE ARE NOW USING A NEW 800- NUMBER

1-866-411-0013 (toll free US/Canada only)
or 1 -800-392-6130 (alternate toll free US/Canada only)

for callers outside the USA/Canada dial 1-734-615-7474 (not free)

Pin # (remains the same): 0142203

Agenda:

1) Startup
      - Roll call, agenda bash
      - Intellectual Property Rights Awareness: Internet2 Intellectual Property Framework
                (http://members.internet2.edu/intellectualproperty.html)

2) Any outstanding Issues?

        - others?

3) discussion of shib + uportal integration (followup from the december thread on the uportal list)

I've pasted in some of the more notable of the postings  from that thread. Several folks from the UK will be joining today's call, as well as (hopefully) James Hong from USC (who initiated the thread).

some of the UK folks (Francisco + ):

At 5:41 PM +0000 1/5/05, Francisco Queiros Pinto wrote:

> I was talking with other colleagues,
> Matthew Dovey (UK  Grid, Oxford eScience Regional Centre
> Technical Manager) and Mark Norman (SPIE/ESP-Grid Project Manager).
> Matthew is also interested in participating in these conference calls.
> Mark would like to attend the first, and depending how technical it
> goes, maybe others.

At 10:45 AM -0800 12/15/04, jkhong wrote:

X-Sieve: CMU Sieve 2.2
Thread-index: AcTi1j+Z9fexoRHbRjaT91398yQV/g==
Date:         Wed, 15 Dec 2004 10:45:29 -0800
Reply-To: Java in Administration Special Interest Group - uPortal
              Discussion List <>
Sender: Java in Administration Special Interest Group - uPortal
              Discussion List <>
From: jkhong <>
Subject:      Shibboleth integration into uPortal
Comments: To:
To:
X-Brown-MailScanner-Information: Please contact the ISP for more information
X-Brown-MailScanner: Found to be clean
X-Brown-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.81,
   required 5, CLICK_BELOW 0.00, HTML_30_40 0.81, HTML_MESSAGE 0.00)

> I looked at
> the archives and didn't see anything specific regarding the
> integration of Shibboleth into uPortal.
>  
> Anyways USC
> is deploying Shibboleth internally.  The intent is for Shib to
> provide identity services for all USC web services.  For now
> PubCookie is providing authentication (authN).  Shib is new
> service as is the USC student portal project which is in development
> stage.  We have purchased Academus 1.3 from Unicon; it is built
> on uPortal 2.1.5.  My task is to integrate Shibboleth into
> uPortal.  I see essentially two things that Shib provides that I
> have to integrate: 1) authentication, 2) identity info - user
> attributes & role info.  Our goal is to de-couple LDAP from
> uPortal completely and have Shib provide all the user identity
> services.  The reasoning is that Shib can be the central identity
> source to control access to user attributes.
>  
> Authentication:
> It was a
> relatively trivial modification to integrate Shibboleth authentication
> mechanism into uPortal.  I used the
> RemoteUserSecurityContext as a code base and had Shibboleth
> populate one of web server header variables with the uid.  I had
> a much harder time modifying code to enable auth chaining with
> RemoteUserSecurityContext but that's another
> story.
>  
> Identity
> info:
> This is the
> part that I cannot get working.  I actually got part of it
> working, but the part that isn't working is the important part
> (Groupstore/PAGS).  My goal was to use PAGS to set up user groups
> from the Shib attributes that are passed.  I modified
> PersonDirectory and PersonDirs.xml (among others) to successfully pull
> information from Shib and stored that information into the person
> object.  So channels can access the shib attributes. 
> Unfortunately the way the Groupstore creates the user groups it is not
> able to access the user's shib attributes; well it probably could
> but it would require a lot of modification which I am trying to
> avoid.  The issue is (as I see it) the Groupstore does not have
> access to the session (or person object that is stored in the session)
> and does not have access to the HttpServletRequest which is needed to
> pull the shib attributes which are stored in the headers.  So
> currently there is no way for me to use PAGS with Shib L. 
> Hence I cannot create user groups from Shib attributes which (to us)
> is the really important function.
>  
> There must
> be other universities out there using Shib for other purposes than
> authentication.  I am hoping that there are at least some efforts
> into integrating Shib services into uPortal - to be able to use PAGS
> with user Shib attributes.
>  
>  
> James
>  
>

At 1:06 PM -0700 12/15/04, Albert Wold wrote:

> This solution will help for many cases,
> but it is not necessarily an elegant solution.  The PAGS really
> needs to be able to access the identity information for any user at
> any time to be able to work properly.  In this case it would only
> be available if the user has (recently?) logged in, and the query is
> on the same application server as the user logged into.  This
> probably won't be a problem for the current applications I'm aware of,
> but I think the group store has a lot of potential future use which
> might be hindered by this type of implementation.
>
> I'm not sure how Shibboleth's user identity information is retrieved,
> but I am assuming it is only provided at the time of authentication. 
> If this is the case, there's really no optimal solution.  I'm not
> a big fan of this model, since I think authorization/identity
> information should be available at any time.  Perhaps this could
> be considered as something to add to Shibboleth.

At 3:40 PM -0500 12/15/04, Andrew Petro wrote:

> Why?  Isn't this a frill feature? 
> Sure, it's nice to be able to look in
> groups manager, click a user, and see his attributes, but I'm not
> seeing
> a use case in which PAGS really needs to know the group of a user who
> is
> not logged in.

(at this point, RL Bob inserted a shib tutorial in the thread)

At 11:11 PM +0000 12/16/04, Francisco Queiros Pinto wrote:

> Shibboleth was mainly designed for
> exchanging authorization attributes across institutions using a secure
> and devolved method where users are authenticated against their own
> institutional access management system (identity provider or origin).
> It's scope is wider than an institution itself, being very suitable
> for scenarios known as virtual organizations, where the Universe of
> users doesn't necessarily belong uniquely to one
> institution.
>
> As far as I know integration of
> Shibboleth into uPortal might be done in at least 2 ways. The first,
> in the way you are trying to do it --let's call it the native way. The
> second by integrating Pubcookie or any other WebIso system such as CAS
> or WebAuth into uPortal, and 'Shibbolizing' only the WebIso
> system.
>
> About the first way, Shibboleth is
> flexible and powerful enough to be used as a native system to provide
> SSO authentication and authorization within an institution. However,
> it is not *yet* so powerful for situations where layered
> authentication (aka secondary authentication or proxy authentication)
> is required, and authorization needs to be later assessed as is the
> case of Portals, or for non-interactive applications involving Web
> Services or Grid environments.
>
> About the second way, you use the WebIso
> system to provide SSO across the institution in the same way as you
> have done with the other SSO-enabled Web-based services. Having done
> this, you 'Shibbolize' the WebIso authentication point (service
> provider or target), at least for all users not coming from a domain
> internal to the institution. For users succeeding to authenticate, you
> grab all the attributes associated with him/her. In the case of a
> Portal, I think one of the attributes has to be a unique identifier as
> the username, email address or something more
> pseudonymous.
>
> I believe most institutions are mainly
> interested in locally deploy WebIso systems, as these systems
> generally provide SSO authentication across the institution. CAS, for
> instance, is really suitable for uPortal and includes layered
> authentication. However, these systems generally provide few or no
> authorization. So, is up to the applications to use local
> authorization systems available (e.g. LDAP), and it makes sense to use
> PAGS to collect further information for authentication and
> personalization purposes. It's worth to notice that LDAP could also be
> used by the WebIso systems for purposes of
> authentication.
>
> I'm involved in a UK JISC Core Middleware
> project --Shibboleth-aware Portals and Information Environments
> (SPIE)-- with the aim to have Portal users seamlessly accessing
> protected services/resources across different information environments
> using Shibboleth. We are inclined for the second way since the 2
> institutions involved are using uPortal and have deployed and
> integrated WebAuth and CAS across the institution applications,
> including uPortal. We also consider the second way less intrusive,
> offering better independence and flexibility for the overall
> institutional infra-structure.
>
> Of course this is work in progress. 
> We are not yet at the same stage as you are, so we will be very
> interested in hearing your progress and happy to collaborate and share
> with you (and all the community) our progress.