At Newcastle we have several applications deployed that use attributes
outside of the need for access control.

Our email list management tool (sympa) uses email address attribute to
provision it's own database, because being an email tool it deals in
email addresses. 

Our wiki (mediawiki) uses eduperson principle name and email address to
provision it's user data stores, it needs email address for when users
want to "watch a page" and get notified on change.

Our group management tool for wiki access is the switch-gmt tool and it
uses eduperson_sn (surname) and eduperson_givenName in addition to email
address and edupersonPrincipleName (eppn) to allow wiki administrators
to figure out who is who and allow access based on eppn....often eppn
and email address are fairly opaque and meaningless and you need peoples
actual names to allow group members to work out who is who when doing
access control.

We use the email address in webforms to auto populate "email address"
fields as we have found that users often mistype their own email
address, likewise when asking for a "username" in a normal webform you
often get what looks like a password. Auto populating these fields can
prevent a lot of administrative burden. In the case of "password instead
of username" mistakes  we have to ask the user to go change it, for
emails often the user thinks they have filled out the form but their
application gets binned because we don't know who they are and can't
contact them. Similarly we are thinking of populating things like staff
card number, employee payroll number for web forms that use them. 

We are looking at future developments where news feeds get tailored
depending on department, course, modules taken, user is staff or
student, user is in stage3 etc etc  Due to freedom of information act we
wouldn't want  these use cases to be about access control. All news
feeds are publicly accessible to all users the attributes would just be
used to enhance the user experience by providing a more "relevant"
default set of news items to users in a portal.

There is some talk about having library fine status so you could either
lock users out of a system until they paid or have nagging messages that
follow them wherever they go.   

The use cases for shibboleth within an institute are far more complex
and in many cases much more useful to the institute than the federated
access model.  All the use cases above are of course utterly doable
using existing ldap and database querying technologies without the use
of shib. However what you tend to find is that the keys to the user data
kingdoms are guarded by people with very little time and little
understanding of anything but their own data. Even the location and
format of data in those stores is non obvious, hence few of the projects
that need user data actually get to access it. By using shibboleth you
abstract away the complexity of the backend data stores, it only has to
be dealt with once by the shib admin not by 20 developers independently.
Using shib enables developers to develop apps without understanding the
university data flows. We have employed a new graduate recently and it
looks like he will deploy more user facing web applications in his first
year of employment than in my 5 years. A large part of this is that he
can rely on shib to provide him with the data his app needs rather than
spending 5 years getting enough seniority and knowledge of what data
lives where in order to be know who to ask and be given access to and
understand how to use relevant user data.    






 >-----Original Message-----
 >From: Discussion list for Shibboleth developments [mailto:JISC-
 >[log in to unmask]] On Behalf Of Nicole Harris
 >Sent: 14 March 2007 15:37
 >To: [log in to unmask]
 >Subject: FW: Looking for examples -- applications using attributes....
 >
 >-----Original Message-----
 >From: [log in to unmask] [mailto:[log in to unmask]]
 >Sent: 14 March 2007 15:26
 >To: [log in to unmask]
 >Subject: Looking for examples -- applications using attributes....
 >
 >One of the major Shib use cases is for the SP to use the
 >Shib-delivered attributes to make an access control decision.
 >However, another important use case is for an application to use the
 >attributes to improve the user experience. An example of this might
 >be an registration application, available to members of the campus
 >community. I'm imagining an application used to register for short
 >training courses offered by the IT or HR departments. Shib could
 >deliver the browser user's name, affiliation, department, and other
 >info that the application wants to record as part of a
 >registration... thus saving the user from having to type all of this
 >info..... there may be related use cases, where the Shib attributes
 >are used to "dynamically provision" the browser user into a system
 >(eg dynamically add students from another campus, who are taking a
 >local course, into an LMS system). And I'm sure there are lots of
 >other related examples.....
 >
 >The Shib team is interested in learning about examples of these sorts
 >of situations. If your site has begun to use Shib attributes for more
 >than just access control, could you post a description of your work
 >to this list?
 >
 >Thanks for sharing!
 >
 >----------------------------------------------------------------------
 >Anything in this message which does not clearly relate to the official
 >work of the sender's organisation shall be understood as neither given
 >nor endorsed by that organisation.
 >
 >
 >----------------------------------------------------------------------