Feature/ckanext iauth

[jbrown-xentity]

Integrating CKAN authentication customizations. Related to GSA/data.gov#2575.

[adborden]

Grab me if some of this doesn't make sense. There's a lot here. This is looking good, but I have some questions/issues about the approach.

I'm concerned we're overwriting the existing auth functions instead of augmenting them (chaining them). We don't want to accidentally allow access because the user exists when the controls should be more nuanced (only allow if user exists and is a member of an organization).

Adding more comprehensive tests would allow us to be sure. We should be testing all CKAN roles as a matrix to be sure we've captured all the cases. When dealing with authorization, we should be thorough in our tests.

[avdata99]

My two cents here @jbrown-xentity @adborden
The functions at get_auth_functions will override (not chain) the default ones (usually just return {'success': True} for read functions). If the only logic (for read functions) is that only logged in users can read all then we probably don't require to chain any action.
I think the decorator auth_disallow_anonymous_access will be enough to all functions that don't require change the logic.

Have we already identified any case where it is required to preserve/chain the previous logic?
If we identify specific cases, then we need to ensure we chain that actions
I don't think we need to chain any action so far

[adborden]

Thanks @avdata99, yeah I think you're right since we're really only touching the read functions, we can get away with validate_user. But if we default to chaining it's less risky and less work. We don't need to track down each built-in auth function to review whether or not to use chaining. If we chain every time, we have our bases covered and makes it fool proof if we add additional auth functions in the future.

[jbrown-xentity]

Create new users:

• GSA admin
• GSA editor
• GSA member
• different org user (admin?) DOI
• no org user

Create dataset with certain parameters on the fly:

• private (true/false)
• name

[adborden]

Looks great! I left a few minor suggestions.

Now that we've dug into all the actions... Is it possible to deny package_show to anonymous users while still allowing access to resources? That way we can get rid of the private -> public upload hack.