Assign auth policies to groups of users

[sco...@artic.edu]

Hello, 

All the examples in the https://wiki.duraspace.org/display/FF/Access+Roles+Module doc page refer to assigning policies to single users. 

How do I assign policies to groups of users? 

E.g I have these users and roles in tomcat-users.xml: 

<tomcat-users> 

<role rolename="aic-user"/>

[...]

<user username="testImgUser" password="******" roles="aic-user"/>

<user username="testAVUser" password="******" roles="aic-user"/>

<user username="testCurUser" password="******" roles="aic-user"/>

[...]

</tomcat-users>

And reflected in Fedora's web.xml: 

    <auth-constraint>

      <role-name>aic-user</role-name>

[...]

    </auth-constraint>

How can I assign a policy for all users in the 'aic-user' role?

Something like this: 

curl -u admin:****** -H 'Content-type: application/json' --data-binary '{"aic-user" : ["reader", "writer"]}' http://localhost:8180/fcrepo/rest/test/testObjAccess/fcr:accessroles

won't work (users get 403 response). 

[Eric James]

Last I checked a couple of weeks I was able to add a role like this:

curl -X POST -H "Content-Type: application/json" --data-binary "@reader_role.txt" "http://testadmin:password@localhost:8080/rest/testaddrole1/fcr:accessroles"

where u:testadmin pw:password is set with "fedoraAdmin" role rights in my jetty-users.properties (should be something similar w/ tomcat-users.xml)

https://wiki.duraspace.org/display/FF/How+to+Configure+Servlet+Container+Authentication

-Eric

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

[Stefano Cossu]

Eric,
My call creates the rule for the 'aic-user' group for that object indeed, but that rule is not honored - e.g. if I log in as testAVUser, which is part of the 'aic-user' group, I get a 403 for that object.

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

You received this message because you are subscribed to a topic in the Google Groups "Fedora Tech" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fedora-tech/gCV_yLB3_Ck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fedora-tech...@googlegroups.com.

[Eric James]

Stefano,

From https://wiki.duraspace.org/display/FF/How+to+Configure+Servlet+Container+Authentication - 

"Fedora currently supports two roles:  fedoraAdmin, which is the superuser role, and has rights to do everything;  and fedoraUser, which is a user role, and must be granted permissions by the Policy Enforcement Point to perform actions"

So I don't think your use case is supported yet.  Maybe something like this may work for the time being, I'm not sure:

<user username="testImgUser" password="******" roles="fedoraUser"/>

<user username="testAVUser" password="******" roles="fedoraUser"/>

<user username="testCurUser" password="******" roles="fedoraUser"/>

curl -u admin:****** -H 'Content-type: application/json' --data-binary '{"testImgUser" : ["reader", "writer"],{"testAVUser" : ["reader", "writer"],{"testCurUser" : ["reader", "writer"] ...}' http://localhost:8180/fcrepo/rest/test/testObjAccess/fcr:accessroles

[Stefano Cossu]

I see. For some reason I was convinced that other roles could be added to the default set.

We'll definitely need more diverse roles than just the three existing ones, so I guess I'll try more flexible solutions than the basic authorization delegate, when they will be available.

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

[Andrew Woods]

Hello Stefano,

As of Sprint 13, there is an example implementation of the "PrincipalProvider" interface that collects principals from request headers:

https://github.com/futures/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/HttpHeaderPrincipalProvider.java

A similar implementation could provide roles from the request's userPrincipal. The implementation would likely require a list of expected/permissible roles in the Spring configuration of the new RequestRolesPrincipalProvider that were checked against the request's userPrincipal. If the userPrincipal contained an expected role, you could then include that "role principal" into the permission checking flow. 

I will note that such an implementation would not be able to simply ask for "what roles do you have" on the request's userPrincipal, as that information is not directly offered by the underlying security framework. You can ask if a user has a role, but you can not ask for all of a user's roles.

This would be a fairly simple PrincipalProvider implementation to write if you and Nikhil would like to take a look.

Andrew

[Stefano Cossu]

Eric,
I tried

<user username="testImgUser" password="******" roles="fedoraUser"/>

<user username="testAVUser" password="******" roles="fedoraUser"/>

and then

$ curl -u admin:****** -H 'Content-type: application/json' --data-binary '{"fedoraUser" : ["reader", "writer"]}' http://localhost:8180/fcrepo/rest/test/testObjAccess/fcr:accessroles

and

$ curl -u testImgUser:****** http://localhost:8180/fcrepo/rest/test/testObjAccess

But testImgUser still can't access the resource. It looks like that access policies can only be assigned to individual users, as per your example below.
Does assigning a role matter at all if assignments are only made on the individual user level?

If I implemented a custom role provider as per Andrew's suggestion, would the repo recognize those roles and assign policies to all the users in a certain role? Or do I need something more complex such as XACML to achieve that?

My goal is to create general, property-based policies (as discussed in https://wiki.duraspace.org/display/FF/2014-04-03+-+Fedora+Committer+Meeting) as well as one-off assignments to individual nodes or hierarchies with the method discussed here.

Thanks,

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

On 4/9/14 5:00 PM, Eric James wrote:

[Eric James]

Stefano,

I came to the same conclusion as you in that policies should be able to be assigned to a role to which a user can belong as an alternative to or in addition to at the user level.  That a user can belong to what is now 2 supported roles (fedoraAdmin or fedoraUser) at the container level, where fedoraAdmin gets full reign while fedoraUser gets further evaluated for reader/writer/admin assignment is not very intuitive to me, but may be in place for good reason.  I would envision some sort of system that extends the fedoraAdmin/fedoraUser role level to allow for any number of roles with property based rule support and fine grained nodal and property targets.  But finding a fedora4 way to abstract these out of code into an XACML like configurable way is indeed a challenge. 

-Eric  

[Stefano Cossu]

Hi Eric,
Thanks for the response. I eventually figured it out (I missed the roles in the containerRolesProvider bean) and the roles are working as expected.
Now I have to maintain my list of roles in 4 places though: tomcat-users.xml, repo.xml, and twice in web.xml (auth-constraint and security-role - the latter in order to avoid warnings)!

I saw in the commit notes that this issue is being worked out, so I hope that in the future it will be easy to maintain a role list.

Thank you,

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

Magritte: The Mystery of the Ordinary, 1926–1938
June 24–October 13, 2014

Members see it first. Join today.

On 6/16/14 5:44 PM, Eric James wrote:

Hi Stefano,

Just checking this now, sorry for the late response.  I think it is currently implemented that you configure using the ServletContainerAuthenticationProvider as the authenticationProvider.  You can then add users using the fcr:accessRoles endpoint to an object or place in the object hierarchy. If you set the fad to BasicRolesAuthorizationDelegate, it will try to match the user in your tomcat-users as a principal to the users you define via fcr:accessRoles on the object or object hierarchy.  The BasicRolesAuthorizationDelegate then makes a decision based on whether the accessRoles principal is set to admin|reader|writer.  Based on some recent changes to the ServletContainerAuthenticationProvider, I don't think it matters what the tomcat-users.xml roles is other than it is not fedoraAdmin.

Someone please correct me if I'm mistaken.

-Eric

https://wiki.duraspace.org/display/FF/Authentication+and+Authorization#AuthenticationandAuthorization-AccessRolesModule
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-roles-basic/src/main/java/org/fcrepo/auth/roles/basic/BasicRolesAuthorizationDelegate.java
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/ServletContainerAuthenticationProvider.java

On Tue, Jun 10, 2014 at 12:37 PM, Stefano Cossu <sco...@artic.edu> wrote:

Can somebody give me some pointers on how to add the roles I have defined in my tomcat-users.xml to my Fedora principals?

I see there is a ContainerRolesPrincipalProvider class in the code but currently roles appear to be ignored. I can only assign policies to users. 

Do I have to include an explicit reference to this class somewhere in the configuration?

I set my repository.json and repo.xml according to https://wiki.duraspace.org/display/FF/Basic+Role-based+Authorization+Delegate 

Thanks,

Stefano

[Andrew Woods]

Hello Stefano,

In the case where you want to use the ContainerRolesPrincipalProvider along with "container managed security", here is the rationale for the role information being recorded in three places:

a) tomcat-users.xml

This acts as the source for authentication. It may likely not be the source of user/role mapping in a production system. The simple "UserDatabaseRealm" which uses the tomcat-users.xml could be swapped out for one of the other Realm implementations that connect to your institutional LDAP-equivalent. 

http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html

Alternatively, you could handle authentication at the Apache2 level.

b) web.xml

This configuration defines the endpoints and HTTP methods that are protected by the container and which roles have access thereto. In the Fedora context, you could have a simple role, "fedora", defined here that all users of the system share. In this way, you could eliminate the need for maintaining all of your institutional roles in the web.xml.

c) repo.xml

You only need to define roles here if you are using the ContainerRolesPrincipalProvider. The idea is that this list of roles is the application-specific set that Fedora is aware of and expects. Instead of requiring this list of roles for the ContainerRolesPrincipalProvider, we could change the implementation to expose all of the roles of the requesting principal to the underlying Fedora authorization logic. We did not go with this approach, however, for two reasons. First, extracting the principal roles relies on non-portable class-casting. Second, from a security perspective, it is recommended to ask, "Do you have role X?" as opposed to extracting the full set of user roles.

Andrew

[Stefano Cossu]

Thanks for the explanation, Andrew. It makes more sense now.

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

Magritte: The Mystery of the Ordinary, 1926–1938
June 24–October 13, 2014

Members see it first. Join today.