[Deploying Sakai] Sakai .auth and .anon Roles

[Adam Marshall]

Likewise .anon access to a site lets all logged in users see the site. The tricky thing here is how the users discover the sites in the first place since they are not members.

We allow all site maintainers to make their sites public in the spirit of openness but we rarely allow .anon so we don’t have to worry too much about expiring and managing  external accounts.

adam

--

** Note change of email address to adam.marshall at it.ox.ac.uk<mailto:adam.marshall at it.ox.ac.uk> **

Dr A C Marshall, WebLearn Service Manager, University of Oxford.
IT Services, 13 Banbury Rd, Oxford. OX2 6NN.


From: production-bounces at collab.sakaiproject.org [mailto:production-bounces at collab.sakaiproject.org] On Behalf Of Steve Swinsburg
Sent: 19 May 2014 04:03
To: Kurosch Petzold
Cc: production at collab.sakaiproject.org
Subject: Re: [Deploying Sakai] Sakai .auth and .anon Roles


Hi

Some sites can be made public which means you don't need to be a member of the site to see things.  This is where these roles come into play.

Cheers
Steve

sent from my mobile device
On 19/05/2014 2:46 AM, "Kurosch Petzold" <kurosch.petzold at fu-berlin.de<mailto:kurosch.petzold at fu-berlin.de>> wrote:
Hey,

sorry for the spam but I got another question could someone please explain
what the special roles .anon and .auth are used for. I found the following
definitions at edia (http://sakai.edia.nl/?p=868):

    The .anon role is the internal role for all not logged in users.
    The .auth role is the internal role for all logged in users who are
not a member of the site.

But what does that really mean?

Thank you,
Kurosch
> Hi,
>
> thanks for your reply. That link was really helpful, though I knew most of
> it already.
>
> Please bear with me as there are some stupid understanding issues
> included.
>
> So my questions are:
> [] First of all there are four models of RBAC in general (Core, Hierarchy,
> Constraint and Consolidate). Sakais model uses something similar to the
> core model right?
>
> [] RBAC96 hierarchy model (I mean hierarchy part) may be simulated to some
> extend with syncs between !site.template.course with course sites (updates
> can be inherited through sync) or through the !site.helper realm
>
> [] Is it possible to have admin roles with different permissions? Have an
> admin without "become user" capability or limited permissions in something
> like worksite setup -> can only create project sites or site and realm
> browser with view only functionality? if not is it planned?
>
> [] Could you elaborate on the groups part? What are they used for, can the
> group.* realms override permissions from site.* realms?
>
>
> [] Just out of curiosity who developed that model?
>
> Thanks,
> Kurosch Petzold
>
>
>> It is custom.  Steve wrote up a good page here:
>> http://steveswinsburg.wordpress.com/2009/05/30/roles-in-sakai-sites/
>>
>> Sites have realms; realms contain roles; roles contain permissions.
>>
>> Sites also contain groups; groups have their own realm; realms contain
>> roles; roles contain permissions.
>>
>> What specific questions do you have about Sakai's role-based access
>> control?
>>
>>
>>
>> On Tue, May 13, 2014 at 12:55 PM, Kurosch Petzold <
>> kurosch.petzold at fu-berlin.de<mailto:kurosch.petzold at fu-berlin.de>> wrote:
>>
>>> Hello,
>>>
>>> is there any detailed documentation available for the role system used
>>> in
>>> Sakai. I know it is Role-Based Access Control (RBAC) but there is
>>> hardly
>>> any information about any specifics how it is implemented or whether it
>>> uses RBAC96, NIST model, another model or a custom model.
>>>
>>> I would really appreciate any help as I need to document how the
>>> complete
>>> role system works for my thesis and it would help us expand our IT
>>> proceedings documentation.
>>>
>>> Best regards,
>>> Kurosch
>>>
>>> _______________________________________________
>>> production mailing list
>>> production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org>
>>> http://collab.sakaiproject.org/mailman/listinfo/production
>>>
>>> TO UNSUBSCRIBE: send email to
>>> production-unsubscribe at collab.sakaiproject.org<mailto:production-unsubscribe at collab.sakaiproject.org> with a subject of
>>> "unsubscribe"
>>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of
>> "unsubscribe"
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of
> "unsubscribe"
>


--
Mit freundlichen Grüßen

Kurosch Petzold

_______________________________________________
production mailing list
production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/production

TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org<mailto:production-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20140519/be334030/attachment-0001.html