Comments (7)
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 valuetrue
)noaccess
(corresponding to the current return valuefalse
)limittedaccess
(for works falling under the FairUse case, when the restriction in China doens't apply)
from bdrc-auth-lib.
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).
from bdrc-auth-lib.
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?
from bdrc-auth-lib.
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).
- 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.
- 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.
from bdrc-auth-lib.
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...
from bdrc-auth-lib.
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.
from bdrc-auth-lib.
that seems to work, thanks!
from bdrc-auth-lib.
Related Issues (14)
- AuthModel loading at startup HOT 1
- add way to give special rights to some IP address ranges
- Jena BUG ?
- bug when reading models HOT 2
- admin interface + API HOT 2
- PUT on large graph called every 5mn HOT 2
- Update time at loading is wrong HOT 1
- more variables in properties
- changing property file configuration HOT 9
- Auth0 authorization extension upgrade
- new release HOT 4
- change test mechanism
- API function to know if the user is logged HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bdrc-auth-lib.