Authorization section

Resource-based authorization overview

The GeoStore Authorization system is focused on the grants that an user has on every single resource. This means that if an user has write and read grants on a resource it can read, update, and delete every single attribute or the resource's stored data.

No more fine authorization is allowed, in order to allow the user to have a partial access to a resource, nor a less fine authorization, in order to allow the user to have a full access/full deny to all resources that belong to a category.

Resource ownership and Group membership

All the authenticated users are able to create new resources. The Resource creator is the Resource Owner and it will have read and write grants on that resource. This behavior is static and the resource ownership is not editable.

By default all non-owner users (except the admin) won't be able to access, both in read and write mode, to a new resource. To allow it the admin, or the owner when creating the resource, must assign a security rule that sets grants for a Usergroup. Of course the non-owner user should belong to that Usergroup in order to access to that resource.

Since all users can be members of many groups, and different groups can have different grants on a single resource, how is determined if a resource can be accessed by an user? It's simple: if the non-owner user belong to at least to one group that has read grants on a resource the user will be granted to readt the resource. Same rule will be applyed to determine write grants.

Resource access based on user IP address

Access to a specific Resource can also be expressed in terms of IP addresses, adding another kind of grant type on top of the user/group association. The restriction to access will be enforced based on the IP address of the user making the request.

This means that a Resource's visibility can be limited by the presence of one or more IpRange constraints which, if none are satisfied, prevent the User from accessing the Resource.

This kind of restriction does not apply if access is already granted by user ownership or group membership. Therefore, a User who has access to a Resource due to membership in a UserGroup will not be subject to IP-based access limitations.

Example

Follows an example:

• Geostore is managing 4 users: the admin, the userOwner and other 3 users user1, user2, and user3 . Note that there is also another special user represented by the guestUser
• Geostore holds 2 Usergroup: groupA and groupB with no users associated

1. userOwner creates resource1

User	Permissions on resource1
userOwner	W + R
user1	No grants
user2	No grants
user3	No grants
Admin	W + R
guestUser	No grants

1. admin assigns user1 to group groupA

2. admin assigns user2 to group groupB

3. admin assigns W grants to groupA for resource1

4. admin assigns W+R grants to groupB for resource1

User	Permissions on resource1
userOwner	W + R
user1	W
user2	W + R
user3	No grants
Admin	W + R
guestUser	No grants

1. userOwner sets an IP range constraint on resource1, with W+R grants

2. user3 has an IP address that is included in the IP range

User	Permissions on resource1
userOwner	W + R
user1	W
user2	W + R
user3	W + R
Admin	W + R
guestUser	No grants