Update authentication mechanism

[etj]

Auth has changed from shibboleth to something similar to a propritary API.

Link to docs: https://servicemanual.services.siag.it/#/nuts-and-bolts/user-authentication/?id=ssocivisbzit Swagger: https://sso.civis.bz.it/swagger/index.html

Sample login procedure

Step1: call to /api/Auth/Login

Params:

• targetUrl: URL for wich the session token is needed
• acceptedAuthTypes: list of auth methods requested
• serviceUID: OPENDATA
• authLevel: authentication level i.e. spid is 2. Default is 0
• onlyauth: authentication only or also possibility to retrieve user profile data. Default false
• lang: it/de

• forceLogin: default false

  As a response to the step 1 we get the URL toward the mycivis portal

Step 2: authentication

After the login you'll get the auth token, e.g. ?token=iromuzdn28uudjozimc2olxhxdv5hnigzh34eju9vi3hiqgcod92fckjhu8sicbu

Using the token you can

• verify the session validation /api/Auth/Validate/{token}

• get the user profile /api/Auth/Profile/{token} -- the onlyAuth param should be set as in the login call

  Step 3: logout

At the end of the session call /api/Auth/Logout

The auth server has a host whitelist for the hosts that needs to use the auth services. localhost is always whitelisted, for all the other hosts we'll need to ask whitelisting for the domains calling sso.civis.bz.it

[etj]

There are 2 kinds of users:

• internal users, that will use the credentials provided in that internal CKAN DB
• external users: they are authenticated in an external system.

External users need also to be created internally in CKAN, because many objects have a foreign key toward an user object; anyway an external user should not be able to log in via username/password using CKAN default auth mechanism.

The external system authentication is called via its own procedure. Full login procedure for CKAN system.

• The user clicks in the "mycivis" button
• The user's browser is redirected to https://sso.civis.bz.it/api/Auth/Login, where the provided targetUrl will point back to a CKAN URL that will take care to finalize the authentication.
  • Please note that the Login service will accept redirection only from enabled/whitelisted hosts. localhost is always enabled, so you can test your local CKAN instance without any problem.
• The external system will ask for its own input and selection, probably providing different authentication methods, that will be transparent to CKAN.
• When the user is properly authenticated, the user's browser will be directed back to the targetURL provided in the Auth/Login call. The redirection will carry with it the query param called token
• The CKAN target URL will be usually only called this way as a redirect from the SSO pages. The service will take care of:
  • retrieve the token from the URL
  • validate the token via the SSO API
  • retrieve the user info (external id, username, ...) from the SSO system
  • check if a related external user already exists in CKAN (using the external id)
    • create a CKAN user if it doesn't exist yet
  • redirect the user to the main CKAN page

From now on the SSO system is not needed anymore, if not for logging out the user when requested. All the session info should be retained in CKAN as per a "normal" login, since the session is bound to a user internally stored.

[Gpetrak]

Thank you @etj for the detailed description of the issue. The related PR can be found here .