OpenID configuration (tC)

There is a possibility to choose between two login types.

With token login, the user must request an access token from the authentication server. With this token he can then request the CMIS interface.

In case of basic login the user requests the CMIS interface with username and password and the CMIS interface then generates an Access Token with these credentials at the authentication server.

Please make sure that the issued access token provides the claim "preferred_username" at the authentication server. This is required for authentication against the CMIS interface.

token

If you have decided to use the token authentication you have to configure an .audience and a .discovery.url parameter in the repositoy.cfg.

The .audience defines the resource identifier. The requested token must provide this predefined identifier so that the CMIS interface can validate access to its resources.

The .discovery.url defines the location of the openid configuration of the authentication server. This endpoint always ends with “/.well-known/openid-configuration“. However, the exact URL must be looked up per authentication server.

<Repo>.authentication.cmis.type                   = token
<Repo>.authentication.cmis.idprovider             = openid
<Repo>.authentication.cmis.openid.audience        = api://cmis
<Repo>.authentication.cmis.openid.discovery.url   = http://localhost:8080/realms/test/.well-known/openid-configuration

basic

The configurations described under token must also be made for basic.

Additionally .scope, .client and .clientsecret have to be configured.

The .scope specifies for which functions the token is to be issued by the authentication server. In our case, the scope must ensure that the authentication server issues our predefined .audience. If the issued token does not have this audience, the token will be rejected by our CMIS interface.

The .client and .clientsecret are basically username and password for authentication to the authentication server. This informations must be read at the authentication server.

<Repo>.authentication.cmis.type                   = basic
<Repo>.authentication.cmis.idprovider             = openid
<Repo>.authentication.cmis.openid.audience        = api://cmis
<Repo>.authentication.cmis.openid.discovery.url   = http://localhost:8080/realms/test/.well-known/openid-configuration
<Repo>.authentication.cmis.openid.scope           = openid
<Repo>.authentication.cmis.openid.client          = test
<Repo>.authentication.cmis.openid.clientsecret    = ETOCuq6c7RjEBwVqrGSDJ2LU4pH4iQbC

role mapping

Both variants support the mapping of roles, i.e. mapping the currently three internal role names to the actually used roles names in the auth system.

<Repo>.authentication.cmis.openid.roles.admin = tia-cloud.core-fullaccess
<Repo>.authentication.cmis.openid.roles.writer = tia-cloud.core-readwrite
<Repo>.authentication.cmis.openid.roles.reader = tia-cloud.core-readonly