Identity Providers, callback locking and the difference between being authenticated and being authorised

[almereyda]

As far as I know the PassportJS adapters can only provide access tokens for whole domains, without leaving subdomains to their respective owners, and as such locked.

https://github.com/fedwiki/wiki-security-passportjs/blob/master/docs/config-twitter.md#configure-wiki explains for example, how the Callback can be left open for the client to be changed.

How can I make sure that logging in to http://patterns.wiki.transformap.co/ does not unlock http://jon.patterns.wiki.transformap.co/ or the whole domain http://wiki.transformap.co/ ?

Would using the Google Adapter help out here?
Or is this closely tied to the wikiDomains configuration variable?
Unfortunately I will not be able to change it every time a user creates a new subdomain.

I have the slight impression this may be just a display error:

Logging me into http://jon.fed.wiki/ provides an open lock on http://patternsofcommoning.fed.wiki/, while trying to edit it sends the changes to localstorage. Signing out here would also sign me out at the source.

In a private tab logging the respective user into http://patterns.wiki.transformap.co/ also unlocks http://jon.patterns.wiki.transformap.co/, while forking of a newer version of the workshop page also creates the yellow halo.

Thus my question ends up to be more about how we can turn the lock icon to be less ambiguous.

[almereyda]

This issue extends so far, that I can log in with any wrong provider in my farm, supposedly unlocking a wiki. Only when trying to provide changes the yellow halo appears.

[paul90]

When you login, with this security plugin, you are performing a login to the wikiDomain and not an individual wiki. This was done so we can support wiki farms with providers other than just twitter without the need to at best add new allowed callback urls (with Google), or whole new applications (with GitHub).

As a wiki farm host, you have to choose which authentication provider(s) you want to use. It makes sense to only configure a single provider, to avoid confusing wiki users.

As a wiki user, when using a farm that provides more than one, you should pick one of the offered providers and stick to using that provider, while accessing that wiki farm.

The 'lock' only indicated if you are authenticated, or not. So, the wiki farm knows who you are. It is not an indication of if you the owner of a particular wiki. This is much the same behaviour we have had with all the previous security implementations.

Would using the Google Adapter help out here?

No. As part of the Google configuration you need to specify all the allowed callback URLs. If you don't use wikiDomain to configure the wiki part of the integration, to provide a domain you will be logging into, you would need to modify the Google configuration each time a new wiki is created to allow an additional callback URL.

If you want to only login to a single wiki at a time, you must only use the Twitter integration as it does not require the oAuth callback url to be configured.

[almereyda]

This is still very confusing and hard to grasp. In continuation of #87 with a slightly different bias, I am receiving errors when logging in to subdomains within the farms denoted as wikiDomains. In use are Twitter and Google Login, which were not constrained as explained in the Configure Wiki paragraphs (1) (2).

# cat config.json 
{
  "farm": true,
  "autoseed": true,
  "security_type": "passportjs",
  "twitter_consumerKey": "",
  "twitter_consumerSecret": "",
  "google_clientID": "-.apps.googleusercontent.com",
  "google_clientSecret": "",
  "wikiDomains": {
    "federated.wiki": {},
    "wiki.transformap.co": {},
    "wiki.allmende.io": {},
    "transforlab.net": {},
    "laniakea.im": {},
    "hypercube.mx": {},
    "chn.io": {},
    "w.id22.net": {},
    "wiki.almereyda.de": {},
    "wiki.geosemantik.de": {}
  }
}

Exemplary debug output looks like:

[ { _: {},
    autoseed: false,
    test: false,
    help: false,
    h: false,
    p: 5000,
    port: 5000,
    '$0': '/usr/local/bin/node /usr/local/bin/wiki',
    farm: true,
    security_type: 'wiki-security-passportjs',
    twitter_consumerKey: '',
    twitter_consumerSecret: '',
    google_clientID: '-.apps.googleusercontent.com',
    google_clientSecret: '',
    wikiDomains: 
     { 'federated.wiki': {},
       'wiki.transformap.co': {},
       'wiki.allmende.io': {},
       'transforlab.net': {},
       'laniakea.im': {},
       'hypercube.mx': {},
       'chn.io': {},
       'w.id22.net': {},
       'wiki.almereyda.de': {},
       'wiki.geosemantik.de': {} },
    valueOf: undefined,
    root: '/usr/local/lib/node_modules/wiki/node_modules/wiki-server',
    home: 'welcome-visitors',
    data: '/root/.wiki/jon.wiki.allmende.io',
    packageDir: '/usr/local/lib/node_modules/wiki/node_modules',
    cookieSecret: '',
    url: 'http://jon.wiki.allmende.io',
    wiki_domain: 'wiki.allmende.io',
    client: '/usr/local/lib/node_modules/wiki/node_modules/wiki-client/client',
    db: '/root/.wiki/jon.wiki.allmende.io/pages',
    status: '/root/.wiki/jon.wiki.allmende.io/status',
    assets: '/root/.wiki/jon.wiki.allmende.io/assets',
    recycle: '/root/.wiki/jon.wiki.allmende.io/recycle',
    id: '/root/.wiki/jon.wiki.allmende.io/status/owner.json',
    uploadLimit: '5mb',
    secure_cookie: false,
    session_duration: 7,
    neighbors: '',
    debug: true,
    database: { type: './page' },
    security_legacy: false } ]
GET /security/security.js 200 52864 - 1.889 ms
GET /security/modernizr-custom.js 200 1807 - 6.123 ms
GET /security/winchan.js 200 10251 - 5.492 ms
GET /security/style.css 200 156 - 4.410 ms
GET /auth/client-settings.json 200 69 - 2.306 ms
GET /auth/loginDialog 200 1518 - 23.995 ms
GET /auth/google 302 0 - 2.165 ms
GET /auth/google/callback?code= 302 74 - 361.406 ms
GET /auth/loginDone 200 1654 - 6.494 ms
GET /security/dialog.css 304 - - 0.727 ms
GET /sandbox.json 200 9118 - 2.223 ms
rejecting /page/sandbox/action
PUT /page/sandbox/action 403 9 - 2.060 ms

How can I debug this further, i.e. why the PUT request is rejected?
Logging in to the farm sites works just fine.

As a wiki farm host, you have to choose which authentication provider(s) you want to use. It makes sense to only configure a single provider, to avoid confusing wiki users.

As a wiki user, when using a farm that provides more than one, you should pick one of the offered providers and stick to using that provider, while accessing that wiki farm.

If you want to only login to a single wiki at a time, you must only use the Twitter integration as it does not require the oAuth callback url to be configured.

Do you suggest the errors comes from wiki.allmende.io authenticating against Twitter, while jon.wiki.allmende.io requires a Google identity? Then the resolution could indeed be to migrate all owner.jsons again to a single provider.

I am not sure about how many scenarios we are looking here and would like to gain clarity about the dimensions at least. Am I missing something other than farmability (discrete; yes, no), number of strategies (discrete; N), callback restriction (discrete; yes, no)?

The 'lock' only indicated if you are authenticated, or not. So, the wiki farm knows who you are. It is not an indication of if you the owner of a particular wiki. This is much the same behaviour we have had with all the previous security implementations.

While it sounds rational to continue with the tradition, as a wiki user I would like to know before a page action (fork, move, ...) if it is going to be applied locally or remotely. This could potentially help to minimise confusion about the different halos.

[almereyda]

Oddly enough, some PUT actions went through, but I cannot reproduce the conditions. The last paragraphs in the following were added today, despite I can authenticate, but not authorise myself against the wiki:

• http://jon.wiki.allmende.io/welcome-visitors.html
• http://wiki.allmende.io/welcome-visitors.html

[paul90]

Do you suggest the errors comes from wiki.allmende.io authenticating against Twitter, while jon.wiki.allmende.io requires a Google identity? Then the resolution could indeed be to migrate all owner.jsons again to a single provider.

Almost certainly, if that is how you have claimed them. I expect that you have probably done this to create some separation of duty, but the reality is that just creating a trap for yourself and potentially others.