Single sign-on based on JWT

Federation server authenticate itself to remote database based on user mapping.

Normally the user mapping contains the local authorization ID and the corresponding remote user name and password. The user name and password are given while the customer creates a user mapping object for a 'server' (remote database) object. In single sign-on it is not required to provide remote username and password. When a user connects to a local database (federation server) using JWT token, and when this user interacts with remote database such as query, remote table etc. the federation server will automatically use the same JWT token to authenticate itself to remote database. This means in single sign-on the user name and password is not needed anymore since the JWT token itself contains the identification and authentication information.

To enable federation single sign-on, the remote database must share the identical security mechanism with federation server, and the remote database must have been configured to support single sign-on. On federation server side the CREATE SERVER statement will be updated to indicate that the remote database supports JWT authentication method and differentiates with other authentication mechanisms, and the keyword AUTHENTICATION and PASSWORD in CREATE SERVER statement now becomes optional.

A new server option SSO_AUTH is introduced to indicate the remote database supports SSO authentication mechanism. When the SSO_AUTH server option is set to 'Y', this doesn’t mean the remote database only support SSO authentication, a plain-text username and password can also be used for authentication when token is not available in Db2 engine. If SSO_AUTH set to 'Y', the 'CREATE USER MAPPING' becomes optional. When token is available in Db2 engine and SSO_AUTH set to 'Y', the CREATE USER MAPPING statement is not required and can be removed safely.

To enable federation single sign-on:

Connect to the local database with a token.

connect to sampledb accessToken <JWT token> accessTokenType JWT;

 CREATE SERVER servername TYPE DB2/LUW VERSION 11 OPTIONS(HOST host, PORT port, DBNAME dbname, SSO_AUTH 'Y');
 CREATE NICKNAME nickname FOR servername.schema.tablename;
 SELECT COUNT(*) FROM nickname;

In this example, the user connects to local database sampledb with a valid JWT token, and then he/she can create server object without keyword AUTHORIZATION and PASSWORD. Also, before issuing a create nickname statement, the user need not a create a user mapping object.

The user can create user mapping optionally as shown below, but the actual authentication to remote database is still based on JWT token.

connect to sampledb accessToken <JWT token> accessTokenType JWT;

 CREATE SERVER servername TYPE DB2/LUW VERSION 11 OPTIONS(HOST host, PORT port, DBNAME dbname, SSO_AUTH 'Y');
 CREATE USER MAPPING for user SERVER servername options(REMOTE_AUTHID 'authid', REMOTE_PASSWORD 'password');
 CREATE NICKNAME nickname FOR servername.schema.tablename;
 SELECT COUNT(*) FROM nickname;

Connect to local database without token
connect to sampledb with username and password;
```
CREATE SERVER servername TYPE DB2/LUW VERSION 11 AUTHORIZATION authid PASSWORD "password" OPTIONS(HOST host, PORT port, DBNAME dbname, SSO_AUTH 'Y') ;
CREATE USER MAPPING for user SERVER servername options(REMOTE_AUTHID 'authid', REMOTE_PASSWORD 'password');
CREATE NICKNAME nickname FOR servername.schema.tablename;
```
In this example, the user connects to a local database without a valid token. In this scenario when the user creates a server object, the keywords AUTHORIZATION and PASSWORD must be provided otherwise the create server statement will fail. The user mapping object must also be created.
Note: The SSO_AUTH can also be set to 'Y', but the actual authentication is based on user mapping rather than JWT token.
If a user connects to a local database without JWT token for the first time and creates federation object as above, and if next time the user connects to a local database with a valid JWT token, when the user queries the nickname, the authentication between federation server and remote database will be based on JWT token.
For example:
```
SELECT * FROM nickname;
```

As the server object is created with SSO_AUTH and the value is set to 'Y', because the JWT token is available this time, the federation will choose JWT token first.