API improvements about bdrc-auth-lib

[eroux]

I just realized that boolean is also not the best return type... I think it should have 3 possible values:

• unrestricted (corresponding to the current return value true)
• noaccess (corresponding to the current return value false)
• limittedaccess (for works falling under the FairUse case, when the restriction in China doens't apply)

[MarcAgate]

I believe that, given a isRestrictedInChina boolean, the following method does the job using Access.hasResourceAccess() as it it in the current version of bdrc-auth-lib:

public boolean isAccessible(HttpServletRequest request) {
        if (access == null) {
            access = new Access();
        }
        boolean accessible = true;
        if (isRestrictedInChina) {
            if (CHINA.equalsIgnoreCase(GeoLocation.getCountryName(request.getRemoteAddr()))) {
                // if Geolocation country name is null (i.e throws -for instance- an IP parsing
                // exception)
                // then access is denied
                accessible = false;
            }
        }
        return (accessible && access.hasResourceAccess(accessType) || fairUse);
    }

More generally, we should use something like https://github.com/buda-base/buda-iiif-server/blob/master/src/main/java/de/digitalcollections/iiif/myhymir/ResourceAccessValidation.java on each server that requires resourceAccess control.

In iiif presentation, having VolumeInfo holding a boolean for isRestrictedInChina and replacing the first constructor by this one should make this class usable everywhere along with the IIIFPresAuthFilter (the controller can instantiate ResourceValidationAccess then calls the isAccessible(HttpServletRequest request) method.

public ResourceAccessValidation(Access access, VolumeInfo info) throws ClientProtocolException, IOException, ResourceNotFoundException {
        super();
        this.access = access
        this.accessType = info.getAccess();
        this.isRestrictedInChina = info.getIsRestrictedInChina();
        fairUse = "AccessFairUse".equals(accessType);
    }

One advantage of using ResourceAccessValidation class is to be able to add some logic specific to the app by decoupling access control from the "more generic" bdrc-auth-lib (as it is the case with Geolocation).

[eroux]

well, yes, that's a first step, but I still think there should be some code to handle the cases where we give a specific user access to a specific resource. The bdrc-auth-lib should be handling that, not the various servers using bdrc-auth-lib. So for instance if we give user bdu:U0001 special access to (otherwise restricted) bdr:W123, bdrc-auth-lib should handle that. Hence we need a second argument in its functions to record that.

I think something like

public static final class Access {
   public boolean isRestrictedInChina = false;
   public AccessType accessType; (where the values are an enum)
}

public ResourceAccessValidation(Access resourceAccess, HttpServletRequest request, String RID) {
   ...
}

I can't remember how we give a user access to a specific resource, but I definitely don't want to implement the logic of reading the auth model and interpreting it into the buda-iiif-server, buda-iiif-presentation, lds-pdi, etc. Do you see what I mean?

[MarcAgate]

As a matter of fact, there is no way to give a user access to a specific resource. Right now, we have 8 ResourceAccess corresponding to 8 accessType and 8 Auth0 permissions (https://github.com/buda-base/bdrc-auth-policies/blob/master/policies.ttl). You can give one or several of these permissions to a user in auth0 dashboard. For instance giving the adr:4d39249c-0896-4dfe-9af4-6b2857868dff permission to a user allows that user to have adr:act1 ResourceAccess so he can view resources marked with AccessFairUse.

For giving a user access to a specific resource, we must create some new policies (within the current policies.ttl file) or in a separate file, outside the authModel (which is loaded and read on each server using bdrc-auth-lib anyway).

1. if we use policies.ttl, we can add something like (doing so, we use auth0 dashboard and conforms to the current design):

adr:cust741 a aut:CustomAcess;
aut:forPermission adr:PermissionW123;
aut:forResource bdrc:W123;

in such a case, we would give the user that Permission in auth0 dashboard and then add the Resource URI as an argument to the public boolean hasResourceAccess() method of Access class.

2. if we skip auth0 and use a custom file (let's say /etc/buda/bdrc-auth/custom.properties), we can have lines like:

userX=W123,W22084,W8475
userY=W451

and then use Property.getProperty("userX") to get a string representing a list of resources accessible to userX. We would then also implement accessControl in public boolean hasResourceAccess() method of Access class.

There are pros and cons for these two solutions. I like the strictness of solution 1) and the fact that no access to ec2 is required for setting up a custom access. However, creating a auth0 permission for each custom resource access (while rigorous) might seems cumbersome.
On the other side, solution 2 requires access (uncontrolled - no need to be a auth0 user or admin, just a ec2 user) to a sensible file (we need access control to this file) and we have to manage a second custom policies source outside the regular policies mechanism. However, solution 2) is the easiest way to associate a user and a restricted resource.

EDIT: I suspect that some of these custom accesses will probably concern at some point "restricted in china" resources. So just as a note, I think we will have to implement some priority of CustomAccess over isRestrictedInChina boolean access control mechanism.

[eroux]

oh ok, I thought this was implemented already. Well, let's not implement it now... but I think it would be relevant to add the RID argument to the functions of the bdrc-auth-lib, even if we ignore it for now, this way we won't need to modify everything in the future...

[xristy]

I agree that the the RID param should be added in anticipation and when it comes time, option 1 seems the better choice to keep the auth coherent rather than fragmented.

[eroux]

that seems to work, thanks!