Hello Heather,

 This is going to sound strange, but Shibboleth doesn't really care about user names and 
passwords. Strictly speaking the task of validating a user is part of the Identity Provider (IdP) task. 
However, the actual authentication is usually handled by an established mechanism.

Let me see if I can explain:

If, for example, you are using an Apache web server, then you can set up the Apache web server to 
"authenticate" users with various mechanisms. One way is to have a text file with user names and 
passwords in it, another is to tell Apache (through it's configuration files) to consult an external 
database perhaps using LDAP. In each of these cases, it's the Apache documentation you need to 
consult to find out what restrictions it might place on characters in user names and passwords 
(although most passwords are encrypted before storage, so there are usually fewer restrictions on 
characters in passwords). If you are using Microsoft's Internet Information Server, you can set it up 
to use an MS Domain or Active Directory. In this case you need to consult the Microsoft 
documentation for NT Server and/or Active Directory and IIS.

Now, in operation, Shibboleth maintains a set of attributes for a particular person. These 
attributes are generally based on the EduPerson definition. It is one of the tasks of the Federation 
to agree with it's members which set of attributes it expects all participants to make available/
utilise.

The UK Access Management Federation for Education and Research is our national federation. 
Their web site is http://www.ukfederation.org.uk/. There are some good documents on this web 
site, you should read through the document library http://www.ukfederation.org.uk/content/
Documents/Welcome/.

The federation documents define the attributes, or point you to the underlying schema 
documentation. 

Shibboleth is intended to seperate authentication from authorisation. Authentication is "who are 
you?", authorisation is "what will I allow you to access". Shibboleth is specifically set up so that 
user names and passwords are not required to be transmitted over an open/insecure network.

 Let's take an example of a school student wishing to access some licensed web content from a 
commercial content provider.

Authentication (IdP):
The school must be "bound" to an identity provider (IdP), this IdP has a web page for the user to 
log in. Here the user name and password are required, but the school network is connected over a 
trusted network to the IdP so there is little risk here. The IdP is registered with the UK Federation.

Authorisation (SP):
The commercial content provider runs it's own web site connected to the Internet. This web 
content is commercially licensed, and licenses are sold to schools such that any user at a school 
can access the content. The web site has been configured to use Shibboleth Service Provider (SP) 
software. The SP is registered with the UK Federation. Now, it's the responsibility of the SP to 
authorise access. To do this, the SP doesn't really need to know who the person is, all they need to 
know is "does this person have an affiliation with a licensed school?". The content provider has it's 
own database in which it registers licensed schools, so all their web site needs to do is get the 
value of eduPersonScopedAffilliation for the person requesting access and compare this with it's 
database of licensed schools. If there's a match, then the requester is granted access to the 
content. If there is no match, then the user is denied access, and, if I were the content provider, I 
would redirect the web page to the "contact us" sales pages!

Usage:
The school student uses a web browser to go to the commercial content provider's web site 
http://www.example.com/physics/.
The web site intercepts this and begins to use the Shibboleth Service Provider software. At this 
point the SP doesn't know anything about the person requesting access. So it redirects the web 
browser to a page to help the user select their IdP, bundling with the request some extra 
information requesting the eduPersonScopedafilliation value for this person. The user will go to 
their IdP and here they will log in. The IdP will authenticate the user, then look up the 
eduPersonScopedAffiliation and redirect the user's web browser back to the SP along with the 
scoped affiliation information. The SP can now decide if the user is authorised to have access or 
not. The important thing to notice is that the user was not required to log in to the service 
provider's web site, so a user name and password was not transmitted across the Internet. Also, in 
data protection terms, the Service Provider does not need to maintain a database of users and 
their passwords, nicely eliminating the poptential risk of loss of data. For the user, once they have 
logged in to the IdP, the session lasts until log out or the browser is completely closed, so any 
further attempt to access SP protected services do not require the user to log in again.

There's a lot goes on under the hood, but the intent here is to make the user experience simpler.

A bit long-winded I know, but I hope it helps.

Kind regards

Paul Mavis
Software Services Delivery Manager
East Midlands Broadband Consortium (embc)

***************** List information: *****************
Remember - replies go by default to the entire list.
Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
To unsubscribe, email [log in to unmask] with the message: leave vle