Hi Daniel
Sorry for the late reply, it is a bit difficult to find time to fit everything in! First thing I would say is that in the UK we are generally using a content management system such as Drupal to provide user authorisation on the client website, and as Indicia is designed to fit into another existing website or CMS providing user authentication as part of the framework has not been a priority. Having said that it would still be useful to have a method of authenticating a user login against the Warehouse. This should use the same digest authentication method as the website login to the web services.

Once you have a user logged in, you should be able to put hidden inputs into your form e.g. sample:created_by_id and occurrence:created_by_id if you are posting a single record in the sample. If you are using the species_checklist then you will need to modify data_entry_helper::wrap_species_checklist so that it treats occurrence:created_by_id in the same way as the record status, and uses the single value for all the occurrence records. If you do this then please submit a patch.

Best Wishes

Hi Daniel
Indicia does not try to impose how you approach these things on you so if you wanted to duplicate accounts then it could be done, though it would help to build a "bridge" module between the Cms and Indicia. But in the projects I have worked on we add a custom attribute called CMS User ID to the sample data and store the ID of the user in the CMS in that field. In fact the created_by fields are only then used to track changed made in the Warehouse itself and are less relevant.
In the only non-CMS based project I have worked on, we simply let the user enter their name against each record as a custom attribute, though this approach is OK for data entry but not so good if the user needs to re-access their own data.
I do agree though - there is a need firslty for clear guidance on the possible approaches to associating records with users with information on the pitfalls of each. Also it would be great to have a bridging module in Drupal (or any other CMS) which synchronises the logins. Finally for the non-CMS method there should be a login helper class which has controls for user registration and login authentication against the Indicia users list. I'll put these notes into the issues list.

Hi

Just for info, I am looking in to the possibility of a mobile application for submitting records to an Indicia warehouse. As every mobile user would have to authenticate to submit a record this is highly relevant and a user registration service would be essential.

Since a mobile app would just be an alternative interface to a survey and there would likely be a website too, using the Indicia warehouse for user tracking would be much better than a CMS User ID.

Jim Bacon

Hi Don

Thanks, this is very useful for clarifying my understanding.

I was thinking that we could abstract the idea of website so, although it might be an umbrella for surveys, it might not necessarily require a website to exist for samples to be recorded.

I realized that distributing a website id and password to many mobile devices would be insecure and, therefore, I thought that each device (user) would have to have a unique id and password.

Since known users can log in to the warehouse website, I could imagine known users being authenticated to access web services. In fact I thought that was what you were doing. Having taken a look at your (beautifully written) code, I can see now that you are using the existing website authentication to access user information on the warehouse.

So, yes, an intermediate website could well be simpler.

Jim

Jim is correct in saying that a website is a rather loose term. Effectively in our context it is a data custodianship tag - which is normally associated with a physical website but not necessarily. Each "website" contains a collection of surveys and also can have ownership of things like custom attributes and species lists.

One model is for the mobile device app to play the role of both the user interface and the "website" and therefore communicate directly with the Warehouse. Although we use digest authentication to ensure that the website ID and password don't get passed around Don is right in pointing out that the website ID and password would have to be configured somehow within the mobile app and there is an element of danger in this. Though perhaps it could be embedded in the app somehow so the user does not need to know it - meaning that each website would effectively have to publish its own app on the app store/market/world.

Don's idea is to present a proxy on the website itself. This is a web address which would receive requests from the mobile apps and attach the website ID and password digest tokens to it, making the request acceptable to the warehouse. The proxy sends the modified request to the warehouse and forwards the response back to the caller. This means the website ID and password tokens don't go in the mobile app at any point, but it does also mean that this URL gives free access to the webservices since it would merrily attach authentication details to any request from anywhere and send them on to the Warehouse!

A possible solution to this problem is to expect the user to login to something first and make the proxy aware of this authentication system. This means it would be able to reject requests from any unauthorised users. In fact, the Drupal modules for Indicia already include a sub-module called iform_ajaxproxy which does exactly this - it sends requests from Ajax code running on web pages for logged in Drupal users on to the Warehouse and attaches authentication tokens, so the Ajax code can be completely separated from the authentication process.

Markus, your best bet for examples of using the data services is to look at the PHP code in the client_helpers folder. In particular the data_entry_helper.php file contains a get_population_data method, used to do simple things like fill a select control with the results of a data services call. For posting the data, look for the forward_post_to method.

thanks for the fast replies,

I guess that for my use-case I will first check, if I can use the Indicia Drupal modules to have the following:
- access by the same users via the website and mobile devices
- have authorizations done at a unique place

I'll check out the php-modules John pointed out above and see if I get it running. In a next step I'll probably
put all that behind an https proxy to avoid sending plain text passwords.

thanks a lot
Markus

Point taken, I hadn't thought about the dependency on not salting the password. So as far as I understand it, the ideal is https and digest authentication would be a second option where https is not available though it is less secure because of password storage been not salted. Therefore they are not compatible so we can't easily turn switch between the 2 methods with an option.

As I've mentioned before Don, rather than try to think through these issues too hard and get something wrong I'd prefer to look for established design patterns to handle the security. This way there is far less chance of us making a mistake.

Threat analysis has only been an informal discussion of the appropriate level of security. We are aware that this is not an industrial strength banking application, but we are also aware that there can be sensitive data stored in the database and that some projects could be quite high profile so being subject to "record spam" would not be a good thing. But if we can find good design patterns for authentication and stick to those, the burden on the project should not be very high.

Website passwords are not salted because this allows the digest authentication to work - as we did not want to pass the website passwords with requests over non-encrypted http. Though I guess they should probably be encrypted.

Yes it makes sense. But, bear in mind recent discussions on the fact that users ought to be authenticating on the warehouse when submitting records. This is because we can then allow cross-discipline recording, e.g. 1 user can submit records to multiple schemes and still keep track of all their records. My recent thinking is that this could be quite important. But if the user creates a login on the client website, does it make any difference if the authentication provider is running on the warehouse? You may not be aware but Don has already written a helper for adding login and forgotten password controls to a client website which uses the warehouse to authenticate. User registration is not done yet though.

In your suggested steps, the "client website" is effectively just a proxy script sitting on the website that forwards requests but also allows some level of data manipulation. I can see the value of this, but also perhaps the option of direct communication with the warehouse when manipulation is not required. This would save a hop and make things a bit more performant.

As you know I had written some thoughts on adopting OpenId in Indicia recently though they don't encompass a thorough thinking through of how this fits with secure submissions, digest vs https etc. To open this up for discussion I am pasting them here:

Common authentication in Indicia
When Indicia is running with multiple websites on a single warehouse, there are many potential benefits to cross site reporting and analysis which come from the data being held on a single database. For example, if websites are set up with a regional focus, verifiers can log in to the database with a species group focus and view the relevant data no matter which website the data was sourced from. Users could also view reports on all their own data, but only if there is a mechanism for recognising a single user across all the websites. In fact having the ability to uniquely identify a person across other Warehouses, the NBN Gateway and other biodiversity information systems such as Recorder could bring benefits in communication across the wider network. Obviously a name or username is not sufficient for unique identification and a user may have several emails, so that is also not sufficient without further guidance.

User Registration on Drupal
Website owners would need to enable the Open ID module in Drupal. In addition it is suggested that they install the Libraries & OpenId Selector modules since the default OpenID implementation in Drupal is quite clunky. The OpenID autoregistration module is an alternative that makes OpenID registration simpler. Note that OpenID Selector is the same library that is used on ISpot so this would give some consistency.

If OpenID is enabled on a Drupal installation with an existing user base, those users need to assign one or more OpenIDs to their account before they can log in using an OpenID. This is accomplished by each user editing their OpenID identity under their user profile. Attempting to login with an OpenID that is not yet linked can easily lead to the creation of a new user if error messages aren't read or understood - and can be confusing to exiting users.

User Registration on the Warehouse
When logging into the Warehouse for the first time, the OpenID Selector JavaScript library can be used to allow the user to enter their OpenID URL. This would let them create a User record though the user would initially have no access to the Warehouse until explicitly granted by an administrator.
There would be a new table for storing Open ID authentications, user_auths. This would contain the User’s Warehouse ID and the associated Open ID.
As for Drupal, if the existing user base wants to start using OpenID then they would need to add their OpenID authentication(s) to their own user profile.

Saving Data
1)    The authmap table can be used to get the current user’s OpenID URLs in Drupal. These can be sent in the submission (perhaps using metafields).
2)    When a submission is received containing Open ID authentication, the authentication is used to lookup the Warehouse user. If the Warehouse user exists, then their user ID is stored in the created_by_id and other metadata fields for the submitted records. If the Warehouse user does not exist then a stub user record is created in the Warehouse and the OpenID authentication is saved in the user_auths table. The response from the Warehouse includes a token requesting that the user’s login is updated. This would cause the iform module to send the user’s Drupal profile to the Warehouse to be stored in the Warehouse user record. The user would not be aware of this.