This is great! I think you just rid of an issue I have been avoiding
to have to deal with! Merci!!!!!
question though: What do you by permissions are remote? remote to the
user or remote to the resources the user is trying to reach? my
thought was that everything is local to the resources
(object,permissions,authorizer)... example:
I am looking into the use of dummy authorizers for ftp access to a
build repository, where I am hoping to use the user's web2py
credentials for ftp access by doing something like:
auth = DummyAuthorizer()
authorizer.add_user('myBuildUser', 'myPassword', os.getcwd(),
perm='elradfmw')
authorizer.add_anonymous(os.getcwd(),perm="elr")
auth.add_user("jerry", "password", "/home/jerry", perm="elr") # read
only
auth.add_user("tom", "password", "/home/tom", perm="elradfmw") #
full r/w access
but this may not be efficient for groups, unless we can retrieve group
info in the users (i'm not smart enough yet to know the answer
here :)
so for groups, I was thinking also maybe:
since web2py and ftp service are on Linux (in my case), and since with
Unix authorizer doesn't store that kind of information at the OS level
(at lest i don't think it does), another solution
would be possibly to add a "global_perm" keyword argument to the ftp
service constructor which would apply to all users (except anonymous).
Example:
UnixAuthorizer(global_perm="elradfmw") # everyone gets r/w at the FTP
level, but we restrict at the OS level.
another option (which I don't how to do yet) would be to add an
function to deal with complicated groups (group a has r/w, groups B
has r only, groups c can r/w in THIS location but not in THAT
location, and our user 'jerry' is part of each group). I was thinking
that one solution would be to have an 'except' function like this:
auth = UnixAuthorizer(global_perm="elradfmw") # r/w for all
auth.except_user("jerry", perm="elr") # except jerry, he gets read
Again, I don't how to do this yet, but will eventually figure out
something (or give up and just give everyone r/w ;) )
Mart :)
On May 23, 11:34 am, Massimo Di Pierro <[email protected]>
wrote:
> we could support CAS 2 by default (with minimal changes) and do
> something like this:
>
> <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
> <cas:authenticationSuccess>
> <cas:user>q234wd325253</cas:user>
> <cas:attribute name="username" value="jdoe"/>
> <cas:attribute name="first_name" value="John"/>
> <cas:attribute name="last_name" value="Doe"/>
> <cas:attribute name="email" value="[email protected]"/>
> ...
> <cas:attribute name="MemberOf" value="group-name"/>
> <cas:attribute name="MemberOf" value="other-group-name"/>
> ...
> </cas:authenticationSuccess>
> </cas:serviceResponse>
>
> On May 23, 10:21 am, Massimo Di Pierro <[email protected]>
> wrote:
>
>
>
>
>
>
>
> > we could expose a has_memmbership and has_permission service to
> > authorized cas_consumers. The problem is that the consumers would have
> > to call special functions to check the provider. We could always
> > delegate the local has_membership and has_permission to the service
> > equivalent functions with there would be problems with referential
> > integrity because objects are local and permissions are remote.
>
> > Has anybody does this (even if not in wbe2py). Is there any
> > documentation?
>
> > massimo
>
> > On May 23, 9:45 am, Michele Comitini <[email protected]>
> > wrote:
>
> > > Could CAS server answer to questions such as "is operation bar allowed
> > > to user foo"?
>
> > > The list of operations is CAS server dependent, the consumer can ask
> > > only for those...
>
> > > mic
>
> > > 2011/5/23 Massimo Di Pierro <[email protected]>:
>
> > > > I have been thinking about this but issue is, how should groups be
> > > > identified? By their name? The consumer app does not have the same
> > > > auth_group table. What if it has a group with the same name as a group
> > > > in the provider app?
>
> > > > Anyway... as it ism CAS (and cas in Auth) has a problem. Any consumer
> > > > can authenticate with it and therefore it will reveal information
> > > > about the user (for example the username and email). There are two
> > > > ways to restrict this: 1) have the provider filter consumers by IP/
> > > > domain; 2) have the user decide whether to authenticate with the
> > > > consumer (as in OpenID). I think 1 is more appropriate for CAS and
> > > > easier to implement.
>
> > > > On May 23, 7:24 am, Ross Peoples <[email protected]> wrote:
> > > >> I am not that familiar with CAS, but it might be useful in some cases
> > > >> to
> > > >> know what groups the user is a member of in the remote web2py
> > > >> installation.
> > > >> For example, if there is an 'Administrators' group that should have
> > > >> access
> > > >> to everything, then you wouldn't have to set up groups and permissions
> > > >> for
> > > >> every single app that uses the remote Auth service.
