nevisIDM Plug-In Implementation Notes

The implementation notes are provided for informational purposes only. Due to changes in the components or best practices, the implementation may change in a future version of the patterns.

nevisIDM Instance Pattern

• The nevisIDM Instance pattern creates and configures an HTTPS nevisIDM instance (that is, the nevisidm-prod.properties file).
• The nevisIDM instance is named according to the name of the nevisIDM Instance pattern.
• The nevisIDM instance requires a TCP service port. It uses 8989 as default.
• Automatically creates a server keystore and server truststore, if none is provided.
• Creates the following configuration files:

The next table lists the properties in the nevisidm-prod.properties file that are relevant for the nevisIDM Instance pattern:

Parameter name	Example value
application.feature.multiclientmode.enabled	true
application.config.file.idmrole.authorization	/var/opt/nevisidm/nevisidm/conf/authorizationConfig.properties
application.config.file.idmrole.mapping	/var/opt/nevisidm/nevisidm/conf/rolesMapping.properties
application.config.file.idmrole.assignment	/var/opt/nevisidm/nevisidm/conf/rolesAssignment.properties
application.config.file.attributeaccess	/var/opt/nevisidm/nevisidm/conf/attrAccess.properties
application.config.file.tldlist	/opt/nevisidm/template/conf/tlds-alpha-by-domain.txt
application.mail.smtp.host	smtp.siven.ch
application.mail.smtp.port	25
application.mail.sender	[email protected]
application.modules.printing.dir.target	/var/opt/nevisidm/nevisidm/generated_PDFs
application.modules.auditing.provider	jsonAuditProvider
application.modules.auditing.file	/var/opt/nevisidm/nevisidm/log/audit-json.log
server.name	New_nevisIDM_Instance
server.port	8989
server.host	nevisidm.siven.ch
server.tls.enabled	true
server.tls.keystore	/var/opt/keys/own/New_nevisIDM_Instance-identity/keystore.jks
server.tls.keystore-passphrase	${exec:/var/opt/keys/own/New_nevisIDM_Instance-identity/keypass.sh}
server.tls.truststore	/var/opt/keys/trust/New_nevisIDM_Instance-tls-client-trust/truststore.jks
server.tls.truststore-passphrase	${exec:/var/opt/keys/trust/New_nevisIDM_Instance-tls-client-trust/keypass.sh}
server.auth.ninja.truststore	/var/opt/keys/trust/nevisidm-signer-trust/truststore.jks

In case it is required to add properties (or override them) in the nevisidm-prod.properties file, the nevisIDM Advanced Settings pattern can be used.

Multi-Instance Setup

In setups with multiple nevisIDM instances, each nevisIDM instance is usually running independently on a different host. However, common practice is that all instances use the same database and share the same data.

These setups require some special configuration, which is described in Recommendations for Special Setups, in the nevisIDM Technical Documentation.

In case of deploying the instance to multiple target hosts, the file auditing and asynchronous processing is enabled on the first instance only. This is to prevent multiple instances from processing the same event concurrently, which may occasionally lead to errors (such as sending out the same e-mail twice, or splitting the audit log file over several instances).

How the First Instance is Determined for Multi-Instance Setups

For multi-instance setups, the instance order is based on the order of hosts in the inventory file. The first host in the inventory file is considered as the first nevisIDM instance.

In case there is only one host in the inventory group, or there is only one host without a group, a single instance setup will be detected. This means that the asynchronous event processing and the file auditing will be enabled on this one host.

Have a look at the following sample inventory file. In this setup, the idmgroup contains multiple hosts. Thus, a multi-instance nevisIDM setup is detected. In this case, the first host in the idmgroup, the idm-01-host.adnovum.ch host, will be considered as the nevisIDM first instance.

schemaVersion: 1

hosts:
- proxy-host.adnovum.ch:
 vars:
 __connection_port: 5522
 __connection_user: root
 __connection_password: superSecret
- auth-host.adnovum.ch:
 vars:
 __connection_port: 5622
 __connection_user: root
 __connection_password: superSecret
- idm-01-host.adnovum.ch:
 vars:
 __connection_port: 5722
 __connection_user: root
 __connection_password: superSecret
- idm-02-host.adnovum.ch:
 vars:
 __connection_port: 5822
 __connection_user: root
 __connection_password: superSecret

groups:
- proxy:
 members: [ proxy-host.adnovum.ch ]
 vars:
 proxy-host-name: https://proxy-host.adnovum.ch:5980
 proxy-bind-address: https://proxy-host.adnovum.ch:80
- auth:
 members: [ auth-host.adnovum.ch ]
- idm:
 members: [ idm-01-host.adnovum.ch, idm-02-host.adnovum.ch ]

nevisIDM Database Connector Pattern

The nevisIDM Database Connector pattern updates database properties in the nevisidm-prod.properties file. The next table shows the relevant properties.

Parameter name	Example Value
database.connection.url	jdbc:mysql://localhost:3306/nevisidm?autocommit=0
database.connection.username	UIDM02
database.connection.password	UIDM02

nevisIDM Password Login Pattern

AuthStates

The nevisIDM Password Login pattern configures AuthStates to implement the authentication flow. The following AuthStates are involved:

• nevisIDM_Connector: Special AuthState that has the nevisIDM connection properties. You can reference (reuse) this AuthState from other AuthStates (for example, from the Generic Authentication Step pattern), via the propertyRef property.
• IdmPasswordVerifyState: Verifies username/password in the given client using nevisIDM.
• IdmChangePasswordState: Covers the "Mandatory password change" use case.
• IdmGetPropertiesState: Displays the Profile selection form if the user has multiple profiles.
• TokenAssemblerState: Creates a custom SecToken to propagate information to nevisIDM.

The next figure gives an overview of the relevant AuthStates and how they are related to each other.

The nevisIDM AuthStates are provided in the nevisidmcl RPM package. This package is added to the classpath of nevisAuth to use the nevisIDM AuthStates in nevisAuth. The system will search the nevisIDM AuthStates via the /opt/nevisidmcl/nevisauth/lib path.

Trust

There are two relevant trust cases:

• When there is a need to verify or change a password, the above nevisIDM AuthStates connect (from nevisAuth) to nevisIDM via SOAP services. To this end, the nevisIDM AuthStates in nevisAuth create a SecToken with the Default Signer KeyStore of nevisAuth. nevisIDM needs to trust this keystore to be able to verify the SecToken and allow the connection.
• After successful authentication through a nevisIDM username/password login, a new SecToken is created and signed with the nevisIDM Signer Key. nevisIDM must be able to verify this SecToken; therefore nevisIDM has to trust the nevisIDM Signer KeyStore from nevisAuth.

Custom SecToken for nevisIDM

nevisIDM requires the following attributes to be present in the SecToken:

• userid
• loginId
• profileId
• clientId

Determination of Client (Tenant)

By default, the Default client or tenant is used for login, and the Client field is hidden on the Login form. However, it is possible to enable the Client field, to allow the user to enter the desired client or tenant name when logging in to nevisIDM.

You enable the Client field with the Show Client Input Field property of the nevisIDM Password Login pattern.

Mandatory Password Change

Upon a mandatory password change, the AuthState will apply the default nevisIDM password policy of the client.

nevisIDM Application Protection Patterns (Services)

Each of the application protection patterns configures:

• The nevisProxy HttpsConnectorServlet, to make the nevisIDM service accessible.
• The nevisProxy DelegationFilter, to propagate the SecToken for the username/password authentication.

nevisIDM Web Application Pattern

The nevisIDM Web Application pattern makes the following administration interfaces accessible:

• The nevisIDM administration UI, on URL: /nevisidm/admin
• The nevisIDM self-administration UI, on URL: /nevisidm/selfadmin

Note that the nevisIDM self-admin web interface is disabled by default. Click [here] for instructions on how to enable the self-admin interface.

The nevisIDM Web Application pattern also configures the CSRF protection for the nevisIDM administration web application. This involves adding a nevisProxy RewriteFilter, which rewrites the domain in the OWASP CSRF Guard JavaScript on the /nevisidm/JavaScriptServlet path.

nevisIDM SOAP Service Pattern

The nevisIDM SOAP Service pattern makes the following nevisIDM SOAP services accessible, on the URL: /nevisidm/services

• AdminService
• SelfAdminService

Note that the pattern does not organize or allow access to the nevisIDM SOAP LoginService. This service is exclusively used by nevisAuth.

nevisIDM REST Service Pattern

The nevisIDM REST Service pattern makes the nevisIDM REST Service accessible, on the URL: /nevisidm/api