That is the best description I've seen on what goes on with S
Hi
That is the best description I've seen on what goes on with Shibboleth
and many thanks for taking the time to write it. It is much appreciated
and between the responses I've had we stand a fighting chance of being
able to use it when the time comes.
Many thanks
Heather Peake
VLE Development Co-ordinator
West Nottinghamshire College
Tel 01623 627191 ext 2292
-----Original Message-----
From: Virtual Learning Environments [mailto:[log in to unmask]] On
Behalf Of Paul Mavis
Sent: 22 March 2007 14:31
To: [log in to unmask]
Subject: Re: [VLES] shibboleth and reserved characters
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this e-mail in error please notify the
originator of the message. This footer also confirms that this
e-mail message has been scanned for the presence of computer viruses.
Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of West Nottinghamshire College.
Scanning of this message and addition of this footer is performed
by SurfControl E-mail Filter software in conjunction with
virus detection software.
West Nottinghamshire College
Derby Road
Mansfield
Nottinghamshire
NG18 5BH
Tel: 01623 627191
URL: http://www.wnc.ac.uk
VAT No: 593 475 93
***************** 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
|
