Provide an upgrade path from WMD 2.x

[mistermarco]

WMD 3.0 needs to provide an upgrade path from WMD 2.x

[mistermarco]

WMD 2.x Settings

Under admin/settings/webauth

Allow / Hide Local Accounts

Stored in the _webauth_allowlocal variable. Are local account login allowed through the usual login block or not? Same behavior as WMD 3.x

WebLogin Link Text

Stored in the _webauth_linktext variable. By default "Login with your SUNetID". Same behavior as WMD 3.x

Post-Login Destination

Stored in the _webauthdestination variable. By default it's blank. Same behavior as WMD 3.x

WebAuth Auto-Login

Stored in the _webauthautologin variable. WMD 3.x will force login on all protected content. WMD 2.x let you choose whether to support that, and it would then be something you could turn on page by page. The nodes where auto-login was turned on, would be stored in the _webauthforce table.

If this is turned on, nodes would get a new option. To see the effects, enable it, then create a page node. You'll see a section called "Auto WebAuth Login" with a checkbox whose label is "Restrict access to this content to Stanford users and force login if user is anonymous."

So, turning on auto-login on nodes would also protect them so that you had to be authenticated to see them. Note: I'm not sure whether this meant you had to be authenticated, or have the SUNet User role.

Node Access Restrictions

Stored in the _webauthrestrict variable. If set, a new option is available per node called Content Access Restrictions. You'd then have the option to check: "Override default access restrictions for this content.". If you did, roles would show, and you could check which ones had access to the node. [More on this further below]

Restricted Access Message

Stored in the _webauth_restrictmessage variable. I believe we are now using the default 403 message from Drupal.

LDAP Lookups

I believe most websites will only have gotten as far as the above settings. Most sites on AFS do not have access to look up membership in privgroups.

LDAP Credential Cache Location

The location of the credentials that Drupal should use when looking up information in LDAP. Usually Apache's cache. Most people don't have access to these unless they run their own server. Stored in _webauth_ldapcred.

Test LDAP Connection: SUNetID and Stanford Workgroup

If you provide a Credential Cache Location, WMD will use it to test if the SUNetID is in the particular workgroup. If it can't do it, it won't save this information. Stored in tstLDAPuserid and tstLDAPgroup

If LDAP access is set up correctly, the "Content Access Restrictions" section will also include a space to add a list of privgroups to use to protect the node.

Content Type Default Access Restrictions

Content types can have default access restrictions similar to what are found on individual nodes.

[mistermarco]

webauth_force database table

This table contains the nid's of nodes that need to force a login, as well as force people to log in. Again, I'm not sure if it uses membership in the SUNet User role for protection, or simply authenticated user. It should be clear from the code.

[mistermarco]

webauth database table

This table contains nodes that are protected, the roles and the sugroups (privgroups). It also has an extra column called inherit which I don't think is in use.

Here's an example of the values you'd find (it's hard to reproduce in AFS because most people don't have access to query LDAP, so, the sugroups fields are likely to be empty for most people):

nid: 3140 roles: a:12:{i:21;i:21;i:13;i:13;i:15;i:15;i:19;i:19;i:20;i:20;i:9;i:9;i:23;i:23;i:17;i:17;i:11;i:11;i:7;i:7;i:22;i:22;i:18;i:18;} sugroups: stanford:stanford, stanford:administrative, stanford:academic inherit: 0

So, node 3140 is protected using the various roles, and by those three privgroups.

For those sites that were able to get privgroup-based protection, we'd have to someone collect all of those workgroups, map them to some roles (maybe new roles named after the workgroup) and then use content_access to protect thoses node using those roles.

[mistermarco]

variables

Needed

I think the following are still needed:

• webauth_allow_local
• webauth_destination
• webauth_link_text
• webauth_sunetid_role

Needed?

Can't this be gotten in other ways?

• webauth_authuser_role

Not sure if these two are needed anymore, depends on testing on proxies.

• webauth_base
• webauth_xhost

Not needed

These are probably no longer needed.

• webauth_autologin
• webauth_ldap_cred
• webauth_pubkey
• webauth_restrict
• tstLDAPgroup
• tstLDAPuserid

Copy to 403 Drupal message?

• webauth_restrict_message

fld variables

I'm not sure what these do:

• fldDummy1_page
• fldDummy2_page

The types of variables (_page is the content type name), show whether content access restrictions are set up as default on a content type, and what roles and sugroups are there. I think similar functionality can be found in content_access

• fldOverride_page
• fldRoles_page
• fldSugroups_page

[ksharp-drupal]

webauth_force: if anonymous user, redirect to the wa_login.php script and also cause the node content to be restricted to the SUNet role (which then depends upon the content access restriction code to keep out logged-in, non-SUNet users.

fldDummy1_page and fldDummy2_page are not used.

inherit: the inherit variable in the webauth table is used when using the content access restriction feature with book nodes to make sure child nodes are automatically restricted as well. Since we're going to the node_access module for content restrictions this can happily go away.

[joshkoenig]

Hey Guys,

Thanks for the documentation. I could use a little clarity here:

1. It sounds like the old WebAuth system had its own mechanism for doing per-node authorizations, and this is being replaced by content_access.module. This seems like a good change, but does the upgrade script need to do this re-mapping?
2. Other than setting a LDAP WebAuthLdapPrivgroups in .htaccess, we don't to any additional lookups in the new module. Therefore we can ignore these settings?
3. Should we look for a list of some nodes in webauth_force as the basis for setting the auto_login variable? Since we're moving from a granular to global value (and I think most use-cases probably want this) if any nodes were set in the 2.0 force table, it makes sense that we'd enable it globally in 3.0.

Hopefully we can talk through these questions this afternoon. In the meantime I will set up a basic update script.

[mistermarco]

I've updated the following site.

https://www.stanford.edu/group/wmddev/cgi-bin/regularwmd/

Pages can now be protected using workgroups as well. The actual protection doesn't work (because the site doesn't have the right LDAP access), but WMD 2.x does write out the database as desired. When a page is protected using workgroups, a new entry is made in the webauth table.

[mistermarco]

I've protected nodes 5 and 7 with workgroups. I've also set up a content type with default WMD permissions to see what happens in the DB (variable table). The name is wmdprotected.

[joshkoenig]

Looking at porting the content_access stuff now.

[joshkoenig]

Ok I have some code, but I need a reality check on if this is the right way to handle the old webauth and webauth_force tables.

Here's what I've got:

• For every node with webauth settings, we can apply those role (or mapped role) restrictions via content_access.
• For nodes marked in webaith_force we restrict them to the default webauth group.

Questions:

1. Is that right?
2. Do we want to force that, or make it an optional post-update action? I'm worried it might actually be confusing and lock people out of content unexpectedly...

[ksharp-drupal]

That sounds right to me. Any nodes in webauth_force should be accessible only to users with the SUNet User role, so I think it is okay to force that - I think it would be worse to inadvertently open restricted nodes to the public than it would be to accidentally lock someone out of content.

-Ken

On 9/16/11 11:41 AM, Josh Koenig wrote:

Ok I have some code, but I need a reality check on if this is the right way to handle the old webauth and webauth_force tables.

Here's what I've got:

• For every node with webauth settings, we can apply those role (or mapped role) restrictions via content_access.
• For nodes marked in webaith_force we restrict them to the default webauth group.

Questions:

Is that right?

Do we want to force that, or make it an optional post-update action? I'm worried it might actually be confusing and lock people out of content unexpectedly...

Kenneth Sharp Senior Web Developer, Stanford Earth Sciences 650-721-6406 ksharp@stanford.edu http://pangea.stanford.edu

[joshkoenig]

Thanks. I'll go ahead and push this code up for review once I'm done testing (shortly).

[joshkoenig]

Looks like more content_access preconfiguration is needed though. Looking at this now.

[joshkoenig]

I think we're good! Please test!

[joshkoenig]

If problems are found, use a dedicated ticket for the edge-case.