SSO Token Login

The SSO token login is a process in 2 steps.

In the first step a token is generated for a user. It cna then be transferred to the entity that needs it (it can be the same).

In the second step, the token is consumed and a session is opened in the name of the user for who the token was generated.

Request Token

POST /api/v1/auth_token/generate/

Authorization rights: A user can request a token for himself. A user with “Super” access type (see Login profile attributes) can request a token for any user of the system.

There are constraints on the target user, it has to be in one of these categories:

• SSO login: the user exists in the Main Server but the APIO is the master of his password, the user himself does not know it and can never connect directly, only via the SSO login mechanism.

• Local login: the APIO authenticates locally the user with respects to its DB, then it opens a session in teh Main Server suing either a shared account or a dedicated account (this last cas is similar to the SSO Login but allows a direct login)

• Main Server login: only if the Main Server offers a similar token based login process. In that case the APIO is just a GW for the token generation.

Example request:

POST /api/v1/auth_token/generate/ HTTP/1.1
Host: example.com
Content-Type: "application/json"

{
   "username": "ApioUser1@sip.netaxis.be"
}

Request JSON Object:

• username (string) – the username of the user for who a token has to be generated

Example response:

HTTP/1.1 201 OK
Content-Type: "application/json"

{
    "loginToken": "1aabd3e6136484ad955463a333dc92c13c4aa844fbe9ace503d43437296baad422112c526e96ec4ca18ebdbb4e9e9d0b4eb226e688df999aa39029aed698aa1a"
}

Response JSON Object:

• loginToken (string) – The token. It has a validity period of 60 seconds.

Status Codes:

• 201 Created – token generated

• 403 Forbidden – you are not allowed ot generated a token for this user (or the user does ot exist)

Consume Token

POST /api/v1/auth_token/login/

Authorization rights: None: this request is sent “out of session”.

Example request:

POST /api/v1/auth_token/login/ HTTP/1.1
Host: example.com
Content-Type: "application/json"

{
    "loginToken": "1aabd3e6136484ad955463a333dc92c13c4aa844fbe9ace503d43437296baad422112c526e96ec4ca18ebdbb4e9e9d0b4eb226e688df999aa39029aed698aa1a"
}

Request JSON Object:

• loginToken (string) – The token. It has a validity period of 60 seconds.

Example response:

HTTP/1.1 200 OK
Content-Type: "application/json"
Set-Cookie: sessionid=0123456780

{
   "ids": {
      "tenant_id": "Apio",
      "group_id": "ApioGroup",
      "user_id": "ApioUser1@sip.netaxis.be"
   },
   "profile" : {
      "user_level": 8,
      "is_first_login": true
   }
}

The answer is similar to the one of a login

Response JSON Object:

• ids (object) – The list of ids of the connected user defined as Ids attributes, to be used by the client to build further API urls. Of course only ids relevant for the type of user connected are returned

• profile (object) – Some properties of the profile as defined in Login profile attributes. The optional parameters are only present if relevant.

Status Codes:

• 200 OK – Session opened based on the token

Configuration Information

For the generation of the content the APIO behaviour is controlled by the following settings (default values displayed):

"BACKEND_CALL_FOR_TOKEN_REQUEST": false,
"TOKEN_REQUEST_FORCE_PASSWORD_IN_AS": false,

Explanation of the parameter:

• BACKEND_CALL_FOR_TOKEN_REQUEST: If true the APIO will first try to ask the Main Server to generatre a token and will try to generate a local token only if the Main Server refuses. If false then only the local token is tried.

• TOKEN_REQUEST_FORCE_PASSWORD_IN_AS: If true and the user login mode is of type SSO_DEDICATED then if the auto)-genrated password is rejected by the AS, the APIO will do a password change and then retry the connection.