buda-base / bdrc-auth-lib

Bdrc authorization library based on auth0

Vagrant scripts for BUDA platform instanciation

The base platform is built using Vagrant and VirtualBox:

1. Install Vagrant and VirtualBox.
2. Download or git clone this repository.
3. cd into the unzipped directory or git clone
4. install VirtualBox guest additions with vagrant plugin install vagrant-vbguest
5. run vagrant up to summon a local instance

Or for an AWS EC2 instance:

1. install the vbguest plugin: vagrant plugin install vagrant-vbguest
2. and run the command: vagrant up or rename Vagrantfile.aws to Vagrantfile and run vagrant up --provider=aws

This will grind awhile installing all the dependencies of the BUDA platform.

Once the initial install has completed the command: vagrant ssh will connect to the instance where development, customization of the environment and so on can be performed as for any headless server.

Similarly, the jena-fuseki server will be listening on:

http://localhost:13180/fuseki

Lds-pdi application is accessible at :

http://localhost:13280/

(see https://github.com/buda-base/lds-pdi/blob/master/README.md for details about using this rest services)

The command: vagrant halt will shut the instance down. After halting (or suspending the instance) a further: vagrant up will simply boot the instance without further downloads, and vagrant destroy will completely remove the instance.

If running an AWS instance, after provisioning access the instance via ssh -p 15345 and delete Port 22 from /etc/ssh/sshd_config and sudo systemctl restart sshd. This will further secure the instance from attacks on port 22.

bdrc-auth-lib's Issues

AuthModel loading at startup

There should be a way to load the model directly from fuseki at application startup. Currently the model is rebuilt from auth0 and bdrc policies, then updated on fuseki.
While this MUST be the case for ldspdi (which is in charge of updating the auth Model when webhooks are trigerred), it doesn't have to be that way on iiifpres or iiifserv.
So two methods in refAuthModel : reloadModel (rebuilts it) and readModel() (which reads the model from fuseki)
Reload() is used in ldspdi, Read is used anywhere else.

changing property file configuration

The way the configuration currently works is way to complex for the deployment (there needs to be tons of files in the git of the various apps, plus some files manually inserted, etc.), here's a proposal for a more simple system:

• the lib reads the system property io.bdrc.auth.propfile.path (which will be set in the systemd files of buda-base, or could be overwritten in some test environment)
• the lib reads the file path which is the value of the property and reads properties from it

and that's all... so there would be just one file instead of two.

Example of property:

io.bdrc.auth.propfile.path=/etc/iiifpres/auth.properties

more variables in properties

The two variables at https://github.com/BuddhistDigitalResourceCenter/bdrc-auth-lib/blob/d26056c6e583311415ca1fd66d8ed1fe81b6e2cc/src/main/java/io/bdrc/auth/model/AuthDataModelBuilder.java#L72 should be coming from properties and not be hardcoded

Auth0 authorization extension upgrade

We need to upgrade Auth0 authorization extension from 2.4 to 2.5. We might have to change a few things as suggested by auth0:

Warning! Read the documentation about breaking changes (https://auth0.com/docs/extensions/authorization-extension) before updating the extension.

Update time at loading is wrong

Currently, update time at model loading is set to zero. Should be set to the current time.

change test mechanism

the test process should be documented, and the test functions that require external files should not be triggered by default so that the lib can be managed without all the machinery

admin interface + API

I think in order for the workflow to be smoother we should have some API endpoints on ldspdi that:

• reloads everything from auth0
• reloads the information about one specific user from auth0 (and not every user)

Also, by doing that we could also:

• when the library looks at a token and sees a auth id that's not in the database, it could just update this user id and update the model of ldspdi, then pushing it on fuseki
• when the library loads it would just load the model on fuseki without going through auth0 (maybe that's the case already?)

with that system we don't depend on the auth0 api so much

API function to know if the user is logged

in the presentation API I need to know if the user is logged so that I can send 401 or 403 accordingly. I think this is solved in the iiif server but I can't really find how... I think it would be worth having a function for that

new release

I can't release this thing, it requires some files in /etc/buda/... @MarcAgate can you make a release please?

API improvements

I'm working on the auth implementation in the iiif presentation api server, and I think we need a few changes in the auth api, especially the hasResourceAccess() function. I think it needs two more arguments:

• the first is a boolean isRestrictedInChina, to match the new model
• the second is an optionalURI of the resource, so that in the future we can have a resource by resource access

Even if we don't implement the logic for the second argument, I think it's important that it's here, so that in the future if we implement the logic, we don't have to change all the calls to the API in the various libs that are using this lib.

Jena BUG ?

here: https://github.com/buda-base/bdrc-auth-lib/blob/master/src/main/java/io/bdrc/auth/rdf/RdfAuthModel.java#L306

I read the following: https://github.com/buda-base/bdrc-auth-policies/blob/master/policies.ttl#L79

and get a the http://purl.bdrc.io/resource-nc/auth/4d39249c-0896-4dfe-9af4-6b2857868dff resource.

jena getLocalName() method returns d39249c-0896-4dfe-9af4-6b2857868dff where the first character ( "4" ) of the local name is missing.

Build test and send it to jena dev

PUT on large graph called every 5mn

see in /usr/local/fuseki/tomcat/logs/catalina.out:

[2021-06-30 00:43:49] Fuseki     INFO  [29775] PUT http://buda1.bdrc.io:13180/fuseki/authrw?graph=http://purl.bdrc.io/graph/authData
[2021-06-30 00:48:33] Fuseki     INFO  [29832] PUT http://buda1.bdrc.io:13180/fuseki/authrw?graph=http://purl.bdrc.io/graph/authData
[2021-06-30 00:53:33] Fuseki     INFO  [29900] PUT http://buda1.bdrc.io:13180/fuseki/authrw?graph=http://purl.bdrc.io/graph/authData
[2021-06-30 00:58:41] Fuseki     INFO  [29977] PUT http://buda1.bdrc.io:13180/fuseki/authrw?graph=http://purl.bdrc.io/graph/authData

this triggers too large a growth in the database size of buda-base/public-digital-library#512

add way to give special rights to some IP address ranges

One of the main missing pieces in the library is the ability to give special rights to some IP address ranges. For instance we want to have in the model something along the lines of:

- rightsForInstitution
   - institutionID bdr:C123 (imagining we have corporation entities for universities, we currently don't but that's another story)
  - additionalRights bdr:CopyrightAccess
  - ipv4AddressRange "1.2.3.0/24" , "1.2.4.5"

(to be modeled correctly in RDF). Then when analyzing the model, the lib would create a trie (using this code which looks good) allowing to match an ip address to a rightsForInstitution and thus additional rights. This means changing a bit the initialization code when creating the user profile but it shouldn't be too difficult... Not an emergency but to be considered...

bug when reading models

see, the stacktrace is:

org.apache.jena.rdf.model.LiteralRequiredException: file:///home/eroux/BUDA/softs/buda-iiif-presentation/དགེ་བཤེས་དགའ་ཉག་པ།
	at org.apache.jena.rdf.model.impl.ResourceImpl.asLiteral(ResourceImpl.java:122) ~[jena-core-3.14.0.jar:3.14.0]
	at io.bdrc.auth.model.BudaUserInfo.getBudaRdfUsers(BudaUserInfo.java:45) ~[bdrc-auth-lib-2.1.0.jar:na]
	at io.bdrc.auth.model.BudaUserInfo.getBudaRdfInfo(BudaUserInfo.java:53) ~[bdrc-auth-lib-2.1.0.jar:na]
	at io.bdrc.auth.rdf.RdfAuthModel.getUsers(RdfAuthModel.java:135) ~[bdrc-auth-lib-2.1.0.jar:na]
	at io.bdrc.auth.rdf.RdfAuthModel.resetModel(RdfAuthModel.java:428) ~[bdrc-auth-lib-2.1.0.jar:na]
	at io.bdrc.auth.rdf.RdfAuthModel.readAuthModel(RdfAuthModel.java:421) ~[bdrc-auth-lib-2.1.0.jar:na]
	at io.bdrc.auth.rdf.RdfAuthModel.init(RdfAuthModel.java:77) ~[bdrc-auth-lib-2.1.0.jar:na]
	at io.bdrc.iiif.presentation.SpringBootIIIFPres.afterStartup(SpringBootIIIFPres.java:77) ~[classes/:na]