08/07/09 12:45:09 (10 years ago)

Update documentation, adding a section on how to set up the security
+ tidy up the codebase, moving configuration files to the top level
and deleting any app specific data + fix a few links to properly
include the admin parameter + fix an issue with the admin redirection.

1 edited


  • TI01-discovery/trunk/OAIInfoEditor/README.txt

    r5466 r5470  
    1313Installation and Setup 
    15 Once the prereqs are installed and the codebase is extracted to a local: 
    17 i) Adjust the content of the config files in oai_info_editor directory as follows: 
    19 development.ini 
     15Once the prereqs are installed and the codebase is extracted to a local dir: 
     17i) Copy and adjust the content of the following config files, from the base directory to the  
     18directory to run the app from (taken to be 'oai_info_editor' here), as follows: 
     20development.ini (or secured.ini if using secured version - see security section, below) 
    2021- adjust the host and port settings appropriately 
    2122- turn debug on/off 
    3940- harvestDir - the directory to harvest OAI documents to 
     42policy.xml - see the security section for configuring this 
    4245ii) Add a config file for the postgres DB used by the discovery service; this is required 
    4346when documents are harvested via the editor - since once the harvest is complete, the 
    5457paster serve --reload development.ini 
     60Running with security 
     62The application is configured to work with the openid based security system available 
     63with the ndg.security package.  To set it up with this, complete the following: 
     651) Get Phil Kershaw to generate specific security certificate and key for your app 
     66- these will be refered to, below as app-security.crt and app-security.key, respectively. 
     67Also get the server encryption certification - we will call this cacert.pem, below. 
     692) Install the various ndg.security eggs - this can be done, e.g. via: 
     71sudo easy_install -Uf http://ndg.nerc.ac.uk/dist/ ndg_security ndg_security_common ndg_security_server ndg_security_test 
     733) In the installed eggs, go to: 
     77and edit the securityservices.ini file as follows: 
     79a) Set the following line (or choose an alternative openid provider): 
     81openid.relyingparty.signinInterface.initialOpenID = https://ndg3beta.badc.rl.ac.uk/openid 
     83b) Set the following: 
     85openid.relyingparty.certFilePath = %(testConfigDir)s/pki/app-security.crt 
     86openid.relyingparty.priKeyFilePath = %(testConfigDir)s/pki/app-security.key 
     87openid.relyingparty.priKeyPwd = 
     88openid.relyingparty.caCertDirPath = %(testConfigDir)s/ca 
     904) Copy the certificate and key from (1) into  
     94and copy cacert.pem into 
     98- also, adjust the port number and hostname, if required; this is where this security 
     99service will be visible from. 
     1015) Start the securityservice app by running: 
     105- this should start the security server - with the logging saying something like: 
     107serving on view at 
     109- if not, diagnose and fix the problems (most likely install issues). 
     1116) Adjust the content of OAIInfoEditor/secured.ini as follows: 
     114authN.redirectURI = http://localhost:7443/verify 
     115- this should point to the service set up to run in (5) 
     119- this should point at the local version of cacert.pem - i.e. ensure there is a copy  
     120of this in the local app ca dir 
     126- again, ensure there are copies of the .crt and .key files in the local pki directory 
     130- this avoids a current issue with ntp time synchronisation 
     1327) The app should then be able to be started in secure mode via: 
     134paster serve --reload secured.ini 
     137Adding new users + enforcing security 
     139Security is enforced by the policy.xml file; this sets what access is required to 
     140view what URLs.  When a new provider user is added to the system, the template in the 
     141policy file needs to be updated.  This should look something like: 
     143    <Target> 
     144        <URIPattern>^/.*badc$</URIPattern> 
     145        <Attributes> 
     146            <Attribute>urn:badc:security:authz:1.0:attr:oai_editor:badc</Attribute> 
     147        </Attributes> 
     148        <AttributeAuthority> 
     149            <uri>https://ndg3beta.badc.rl.ac.uk/AttributeAuthority</uri> 
     150        </AttributeAuthority> 
     151    </Target> 
     154- in this case, any URL which ends in 'badc' requires the user to have the 'badc' role 
     155in order to view.  Every new provider in the system (e.g. by an admin user) will need 
     156a new target added to enforce the required security.  Phil Kershaw can then set up 
     157any required users for this provider. 
     159In the case of admin users, all admin functions are accessed by appending '?admin=1' 
     160parameter to the URL - and this is handled by the target: 
     162    <Target> 
     163        <URIPattern>^/.*?admin=1$</URIPattern> 
     164        <Attributes> 
     165            <Attribute>urn:badc:security:authz:1.0:attr:oai_editor:admin</Attribute> 
     166        </Attributes> 
     167        <AttributeAuthority> 
     168            <uri>https://ndg3beta.badc.rl.ac.uk/AttributeAuthority</uri> 
     169        </AttributeAuthority> 
     170    </Target> 
     172- this keeps things simple.  New admin users just need to have the role,  
Note: See TracChangeset for help on using the changeset viewer.