Dataset authorisation info
This document describes how the authorisation system works. It covers public, registered user and restricted resources.
To set up access control fully there are 3 systems that need interacting with:
- securityDB - this is where the actual access control within the archive is set for FTP and web download access
- userDB - this is where the application system is set up and maps to user accounts for actual user access
- MOLES - to provide the link for people to register/get information on access control/licencing that is in place
In addition to these systems that related to CEDA Archive users there is also direct JASMIN access to consider. That is based on LINUX groups and how particular archive 'access groups' map to these linux groups. For more information on that aspect see the Login Services access to archive page.
For the following 'access group' refers to the archive access group NOT the Linux group.
Important basic principles to note
- To proceed you need to know the archive path where you wish to set the rules to apply. This does NOT have to be done for every dataset within a given point in the archive, but could be higher up the directory tree if there is a common access control that applies to all the datasets within a given part of the archive.
- A 'default' entry can be set at this higher point which can be overwritten/superseded by a more specific rule further down.
- These more specific rules can be set to expire and then access will go to the default option. This is very useful for embargoed data where the embargo will expire on a given day.
- The default rule, if nothing is set, should be to prevent people from accessing the data, but beware of what has been set further up the directory tree!
- for 'restricted data' a 'group' can be used to give access to a set of resources where the access control and licencing will be in common.
1. Licence file
From the DMP you should have an idea of what licence is needed for the data you are looking to get up access control for. Ideally, it should be one of the common licences. The 'licence selector' spreadsheet can help determine this. NOTE this also includes two generic licences specifically designed for 'embargoed/restricted access' data (the RUGL and RUNCGL licences), which should remove the need to create any bespoke licences in most cases!.
However, should you need to have a new, specific licence not already in the CEDA Artefacts server then :
- get a PDF of the licence file
- add it to the CEDA Artefacts server under the licences/specific_licences folder (via the version control system - this will be rolled out to the live CEDA Artefacts server in due course).
- Inform Graham that you've added a new licence as this will then need to be classified for the types of use the licence permits.
2. Set up securityDB rules
This is where the '.ftpacecs' and XACML policy files are set. The .ftpaccess files control access via FTP and XACML policy files set the web access control.
- login to http://securitydb.ceda.ac.uk/admin/
- select 'paths' and do a quick search for the upper most directory covering the path you want to set a rule to see what has already been set
- select 'add path', top right
- enter the path where the rule should apply
- below that in the 'rules' box select 'add another rule'
- set 'operation' to 'read files' then select the access type - select ONE only of :
- 'public' for fully 'public' data (non-registered user AND registered users will have access).
- 'reguser' from the Groups list
- another 'group' from the Groups list. If you need to set up a new 'group' use the green plus symbol REMEMBER THE SELECTED GROUP! This should be lowercase, with no spaces and use '[a-z0-9], '-' or '_' as needed
- If required, set expiry date for the rule
- Add comment if you wish
- click Save
- back at http://securitydb.ceda.ac.uk/admin/ select 'cron runs' - this is where ensure the system knows to pick up the rule and enact it
- check for a shorter path covering your rule already - if there isn't something then select 'add cron run'
- enter path and select 'execute in cron job' and 'Generate xacml for pydap browser' to enable ftp and web access
- You can also select the 'demo' option on the 'cron runs' screen to get an idea of the .ftpaccess files that will be enacted.
- the 'Do it now' option will squirt out the required .ftpaccess files into the archive.
3. Set up CEDA userDB entries (for 'restricted data')
IF you have set up a new group in step 2.6c above you will also need to set up the access application route in the CEDA UserDB as follows:
- log into http://cedadb.ceda.ac.uk/admin/udbadmin/
- under Datasets select 'add'
- enter the new group as defined for 2.6c above in the 'datasetid' and 'group' fields. Fill all other fields in as per the table below:
datasetid Identifier for this entry in the table. This should normally be the same as the 'group'. authtype Authentication type. The registration system recognises the values 'online' or 'manual'. The other values which have been used are 'public' if the group has been made public following a period of restricted access, 'none' if the dataset has been removed, 'internal' if this group will only be assigned manually by the BADC team, or 'badc' (?? can remember what this represents ??). group This is the group name which is used to control access to the dataset. Ideally this should be the same as the datasetID (to reduce confusion). This will be the name that you use in the .ftpaccess file(s). description Text description of dataset that will appear on various forms (some of which will be seen by users). This should be short and meaningfully convey what the application will get access to directory not used any more conditions URL of the PDF file containing the licence to be used in the applicaiton process. defaultRegLength Default number of months before users dataset registration will expire. Value can be modified when dataset is approved. dataCentre 'badc' or 'neodc' (not used) infourl This is a url which points to a page that gives information about what this group provides access to. This will appear as a link in the 'my groups' section of MyCEDA and may be used in other places in the future. If there is a one-to-one relationship between this group and a dataset then this page could be the dataset page. However, if there is a more complicated relationship (eg. only providing access to part of a dataset) then you should create a page explaining how this group works and set infourl to point to it. Associated linux group id not used anymore Check for public key not used any more comments Any comments, for internal documentation purposes only.
- Select 'save'
- If authtype was set as 'Manual' then go to http://cedadb.ceda.ac.uk/admin/udbadmin/privilege/. Here is where to set the external authoriser for the resource - for this you will need to know the CEDA user account of the authorisers for the data.... or CEDA helpdesk if this is to be used
- Select 'add privilege'
- look up the user for the 'userkey' using the looking glass icon to the right of the box and searching in the pop-up dialogue
- select type to be 'authorise'
- Select the dataset ID that you have set up as per step 3 above
- add a comment and save
This will then enable you to test the application system. To do this use the following URL (replace the <datasetid> with the one you've set up:
Fill in the application and submit. This will send the first 'authorisation' email off to the external authoriser.
4. Set up Catalogue (MOLES) 'permission/Constraint' for datasets
The final step is to then make sure that the access control and licencing is conveyed to the user and provide the link to gain access if required. This is done via the CEDA data catalogue (MOLES) using an record called a 'Constraint' object... these are linked to Dataset records (Observations) via the 'permission' field.
NOTE - Where possible, pre-existing 'Constraints' should be used. For example, for 'public' access under the Open Goverment licence then the Constraint object to use is: https://catalogue.ceda.ac.uk/admin/cedamoles_app/constraints/129/. If you're not sure of the licence at this point, don't worry - there is a constraint object for that too!
4.1 Setting up a new Constraint object
- go to https://catalogue.ceda.ac.uk/admin/cedamoles_app/constraints/ and check for Constraints that already meet your requirements and re-use
- else click the 'add constraints' button
- give a label that is meaningful to help search for the constraint object
- select access category to match that set in the securityDB
- IF access category is 'restricted' then add in the Access Roles - i.e. the 'group' set in step 2.6c
- Add a link to the licence file in the CEDA Artefacts service
- Select Save
4.2 Linking to Observation/Dataset record
- Open up Observation record to add 'constraint' object to
- find the 'permission' box and search for the constraint you require and select it...
- save the Observation record
- check the user-view.. if record is not in 'preview' there should be an appropriate button displayed - e.g. Apply for Access. Informaiton should also be under the 'details' tab.
- If able to - check that the 'apply for access button does work