Create session cookie so headers are only needed on login page

[mauritsvanrees]

Currently the headers are needed on every page. When the headers are gone, you are no longer logged in. It would be useful if you stay logged in. Then a frontend server (nginx, Apache) only needs to check for example SAML or CAS only for one, or a few, pages.

• We can set an __ac cookie by calling self._getPAS().updateCredentials.
• That will call updateCredentials from plone.session.
• For that call to work, a user must be found. That can only work when our plugin supports enumerateUsers, although possibly a user with the same id can be found from LDAP or elsewhere.

So:

1. Implement enumerateUsers (this will either return one user or none, depending on the headers).
2. Call updateCredentials. I think we would call this from authenticateCredentials.

Ah, or we would just call _setupSession from plone.session directly.

[mauritsvanrees]

Problem: with the idea above we can set an __ac cookie with a ticket. But on a url without the headers Plone will then check this ticket, and will make a call to pas._verifyUser. This will fail (give None) when a user with this id is not known in the site.

Options:

• Rely on another plugin for listing users. If the user is known in the standard source_users it will work fine. It will probably also work for LDAP users when you have a plugin for that.
• Otherwise, our plugin would need to create a user when it sees headers. This could be a simple BTree, or other tiny persistent data structure. Or maybe a volatile attribute. Just the user id would be enough. Possibly add the extracted user properties. We would need to implement enumerateUsers to read this data structure, like I thought at first.

So we might need a few extra options for our plugin, by default false:

1. Create a session cookie ticket: yes/no.
2. Create simple users on the fly: yes/no.

I guess all four combinations of yes/no could be valid, depending on your use case.

[mauritsvanrees]

Current plan:

• Add the first option mentioned in the previous ticket: create a ticket yes/no. Some organisations will want this, others not.
• When the option is true, in our authenticateCredentials we check with _verifyUser if we know a user with this id.
• If we do, then we set up a session cookie/ticket, otherwise not.

Optionally creating simple users on the fly is nice for later. I don't need this for my current client.
Note: it would involve storing the properties and roles too.