User Directories Overview, Pros and Cons
Overview Secure ISMS can operate with one or more of the following user directories. Secure ISMS Users (ISMS) Internal users local to the Secure ISMS application Microsoft Active Directory (AD) Direct LDAP/LDAPS connection to a Domain Server Active Directory Federation Services (ADFS) User validation by an internal/external Microsoft ADFS Server Azure Active Directory (AZURE AD) Active Directory as a Service in Microsoft cloud Azure Google Directory (GOOGLE) User directory service in Google cloud Functionality ISMS AD ADFS AZURE AD GOOGLE User Authentication, users enter id and password X X User Authentication, button on login form X X X Single Sign On (automatic login) X X X X Nightly user and groups synchronization X (X) Password hash stored in Secure ISMS Onetime passwords, forced password change X X Two factor authentications X X X X X Audit log with detailed login information X X X X X
User Authentication, forms login This will allow users to enter a user id and a password, and Secure ISMS will try to match it with Secure ISMS users in the local database. Having at least one administrative user defined in the Secure ISMS provider, ensures that it is always possible access the settings pages, even if the link to an external directory provider is broken. If one or more AD connections are configured, it will also try to authenticate with AD. If the user is authenticated by AD, Secure ISMS will fetch a list of groups the user is member of and adjust the users access rights accordingly. When using forms login, it is recommended to allow https connection only, so passwords are only transported through and encrypted connection. User Authentication, button on login form Users can press a button on the login page, and they are redirected to the external directory provider. If the user s browser is already logged in, the external directory server will redirect them back to Secure ISMS with the need information about the user. If users need authentication, the external directory server have different option for user authentication like challenge response, certificates, or a form-based login page. A successful ADFS login response already contains detailed information about the user, including a list of the groups the user is member of. With Google and Azure AD, the response only contains a token, which allows Secure ISMS to fetch user information and group membership.
Single Sign On Google and Azure provides SSO by being able to reuse user authentications saved in the browser, so users are not prompted for identification as long as the saved authentication is valid. ADFS can provide SSO if the user and ADFS directory provider is on the same network. ADFS it is able to reuse the user s windows login and log users into Secure ISMS without prompting the user for ID. ADFS is also able to use certificates and form login to validate a user when users are not on the same network as the ADFS server. AD can provide SSO when an AD service user is provided in Secure ISMS, and Microsoft Internet Information Server (IIS) is used as a reverse proxy frontend web server. IIS is able to use the user s windows login to validate them in AD without a prompt for ID, and Secure ISMS is able to lookup detailed information about the users with the service user account. Nightly user and group synchronization When Secure ISMS is allowed to import and synchronize users and groups, you are able to delegate access rights and task responsibility to users or groups which have never logged into Secure ISMS. Otherwise you will only be able to delegate to user that have signed into the application at least once. AD configuration in Secure ISMS, allows you to configure an AD service user. This account is used to import and synchronize all or filtered users and groups from your AD every night.
Nightly synchronization with Azure AD is planned. Password Stored in Secure ISMS Only Secure ISMS internal users have password information stored in the database. All other users are always validated against the external provider at every login. Even for Secure ISMS users, passwords are never stored; only salted hash values are stored so it s not possible to unpack or unencrypt a stored password. Onetime password and forces password change Only Secure ISMS internal users have the option to have a onetime password mailed to them as part of an I have forgot my password process or initiated by an administrator. Some of the external directories services have the same functionality, but that is not initiated or provided by Secure ISMS. Two factor authentications All users have the option to enable two factor authentications for their account. With two factor authentications, users are asked for an extra login code, which changes every minute. Users can install a code generator on their computer or mobile phone to generate the codes. Audit log with detailed information Secure ISMS contain a log with detailed information on all logins for the last period. User logins are logged no matter which user directory granted the access, and both user interface and API access are logged. Additional and extended user authentication logging is also provided by the external directories. This allows for a centralized user authentication log for multiple applications.