Using the MDS for HTTP Authentication
This page details how to set up web pages to use the Monash Directory Service to authenticate users. It helps if you have some understanding of apache configuration using the .htaccess file. Extra information about .htaccess files can be found at the following page: "Directory Level Apache Configuration Files".
Monash CAS notes
CAS is the same syntax and same form as the authentication on the intranet server where all authenticated material will need to reside by the end of 2010.
Setting Up Authentication
Edit a file called ".htaccess" which lives at the top of the document tree you wish to protect on the webserver, eg:
A standard .htaccess file for a Monash-only web page would be:
order deny,allow deny from all allow from 130.194 monash.edu.au
To use the Monash Directory Service for authentication, it would be something like:
order deny,allow deny from all allow from 130.194 monash.edu.au AuthType Basic AuthName "Monash Directory Service (authcate)" AuthLDAP on AuthLDAPServer ldap://directory.monash.edu.au/ AuthLDAPBase "o=Monash University, c=au" require valid-user satisfy any
which means "if the user is coming from inside Monash, feed them the page straight away. If they're outside Monash, ask them to enter a username/password pair for access to the page and any subsequent pages protected by the same "AuthName" line listed above".
Eventually it is hoped to factor out these two lines...
AuthLDAPServer ldap://directory.monash.edu.au/ AuthLDAPBase "o=Monash University, c=au"
...by adding them to the main server configuration, since many people won't need to change this unless they want to restrict access to (for instance) Staff-only, Department-only, and so on.
How do the users validate themselves?
The browser will pop up a dialog box asking them to enter a username and a password. Note that they only have to enter that password once per browser session as long as the .htaccess file for each group of pages use the same "AuthName" string.
Further examples on restricting access
All of these examples involve replacing the line "
Restricting access to a single user
If the user's user ID is
require filter "(uid=ajft)"
Restricting access to an arbitrary list of users
require filter "(|(uid=ajft)(uid=eddieshe))"
This one means "anybody who has an
require filter "(ou=Micro Computers Activity)"
If you want to restrict access to pages by a student's subject code, you can do something like this:
Require filter "(monashenrolledsubject=mat2040)"
Restricting access to a group
The groups that are mentioned next exist as an object in the Monash Directory Service which contains the list of members as "uniqueMember" attributes. For example, the group called "MMS Development Group" contains the following members:
uniqueMember=cn=Andrew Cosgriff, ou=Computer Centre, ou=Computing Services, ou=Staff, o=Monash University, c=au uniqueMember=cn=Nathan Bailey, ou=Computer Centre, ou=Computing Services, ou=Staff, o=Monash University, c=au ...(and so on)...
To restrict access to this sort of group, you can do :
require group "cn=MMS Development Group,ou=Computer Centre, ou=Computing Services, ou=Staff,o=Monash University,c=au"
...where the long thing inside the quotes is the DN (Distinguished Name) of the group object itself.
Note: The webserver LDAP module currently doesn't check recursively for group membership, ie. it will only work for people who are direct members of the desired group, as opposed to, say, someone who's a member of a group that itself is a member of the desired group. Recursive group checking will hopefully appear at some later stage.