buda-base / bdrc-auth-lib

Bdrc authorization library based on auth0

bdrc-auth-lib

Bdrc authorization library based on auth0

Releasing on Maven

mvn -DperformRelease=true clean deploy

See https://buda-base.github.io/bdrc-auth-lib/

Setting up and using mkdocs (https://www.mkdocs.org/)

Install:

MacOS

https://www.jeannot-muller.com/how-to-install-mkdocs-on-macos/

Linux

http://learn.openwaterfoundation.org/owf-learn-mkdocs/install/#install-on-linux

To edit buda-edit documentation website:

1. clone bdrc-auth-lib repo

2. cd documentation/docs and edit markdown files.

To build the site:

In bdrc-auth-lib/documentation, run sudo mkdocs build

To serve it locally: run mkdocs serve (it will be served on localhost:8000)

To deploy it : run mkdocs gh-deploy (it will be served on https://buda-base.github.io/bdrc-auth-lib/)

bdrc-auth-lib's Issues

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

new release

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

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

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]

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

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

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...

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.

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

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.

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

Update time at loading is wrong

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

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