Role-Based-Access-To-Sites

Owned by Former user (Deleted)
Dec 10, 2015
2 min read

This feature allows one to grant additional access to a site to Role Groups - this are defined by implementing a Role Provider. Examples include "Public" access (.anon role), "All Logged In Users" (.auth role) which are both already built in to Sakai, but can also include new roles defined locally such as "All Staff", "All Students", "All Retired Staff" and so on.

The QA Server / Trunk comes with a demo role provider for testing. This implementation could be used as the basis of a locally written provider to define roles that make sense locally. This is what we have at Oxford: "All College Staff", "All Senior Members", "All Oxford Staff and Students" (which of course excludes external "gmail-type" accounts).

Many people don realise that ".auth" & ".anon" are actually 2 roles that are in Sakai by default. This is slightly confusing as most people think of ‘instructor’, ‘maintain’ etc as roles but ".auth" and ".anon" are called roles too. (As a side note, we have disabled the showing of ".auth" at Oxford so that people with external accounts cant do that much in the system. This can be done via a property. ".anon" can also be disabled by a property.)

When Sakai is started in demo role the demo role provider should be used, when started in production mode it should not. In both cases, .auth and .anon should be shown ujnless disabled.

If,for example, the “All Staff” role has been implemented in the Role Provider and has been granted access to a site then that will allow anybody with that “User attribute” to visit the site, providing they know the URL. (I say this last bit because the site in question will not appear in their My Sites drawer because they are not a site member – they can be given the URL or can search for the site using “Find Sites” / “Sitebrowser” tool.)

To determine whether a user can visit a site (ie, has the correct "User Attribute", their UserID (or is it user object, I forget) is given to the Role Provider which checks their attributes against the site’s ‘additional access’ policy and then says “yes” or “no”.

It’s a brilliant feature and Oxford uses it all the time as it allows a site to be visited by (say) 100,000 users without running into all the performance problems that adding 100,000 site members would incur.

Please contact me (or comment) if you want more details.