buda-base / bdrc-auth-policies

A repo for bdrc-auth policies

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-policies's Issues

Add Apple as a login option

Apple needs to be added to the Auth0 login panel.

user group based on collection of works

Similar to issue #2 we need a means of associating a full readonly access privilege to a collection of works such as with IP address ranges associated with Core Text Collections.

The application is for translators such as the 84000 amorphous team that need full read access to the pedurma katen - which is copyrighted. Essentially we create an adm:Product or a bdo:VirtualInstance that includes a set of Instances, like W1PD96682 and bdr:W1PD95844 and then associate a set of users that can have full read access to these instances.

Something like:

bdr:Pedurmas 
  a :VirtualInstance ;
  :hasFullAccessGroup  bda:Group84000 ;
  :hasMember  bdr:W1PD96682 , bdr:W1PD95844 ;
.

IP address ranges that are used in Core Text Collection are not suitable for this use case since the users aren't tied to a predictable set of IP ranges; and the blanket read-only user access to all copyrighted works afforded by the group 84000 in tbrc.org is much too broad.

Extending endpoint securitization to request method

See description of the issue here: buda-base/editserv#10

no password reset email

Karma tried to reset his password but didn't receive any email from auth0... not sure how to debug that but let's track it there

defining IP ranges

We need to be able to add the IP addresses of the institutions that pay for the CTC collection, and be able to give people who connect with these IP addresses a special group, which is part of the CTC group.

So we would have something like

adr:CTCAccess a aut:Group .

adr:CTCInstitution1 a aut:Group ;
    aut:partOfGroup adr:CTCAccess ;
    skos:notation "institution1" ;
    skos:prefLabel "a name for institution 1"@en ;
    aut:IpAddresses "1.2.3.4/5" , "2.3.4.5/6" .

once we have the vocabulary for that we can migrate the current bdrc data. Then in bdrc-auth-lib we need to have a function to match an ip address against all the groups and add the group to the user profile on the fly.

@MarcAgate no emergency but I think now would be a good time to do so since we're making some changes on the user and auth stuff. Wdyt?

Changing prefix

@Prefix adr: http://purl.bdrc.io/resource-auth/ should become @Prefix adr: < http://purl.bdrc.io/resource-nc/auth/>