You can set your custom Authentication Policy for your users.
The Policies page shows the default settings and by clicking on “Edit“ you will enter the Edit mode where you can set your own policy settings and add restrictions which will apply to all users from the domains you have registered.
Identity Providers
In this section you have by default all Identity Providers checked, meaning all are by default allowed to be used for authentication for the users from your registered domains.
In order to disallow Identity Providers, you have to understand some basic concepts:
Each application used by your users has a certain set of Identity Providers shown by default on the sign-in page, so not all from this list are used by all applications on the sign in.
Each application can have some logic to require a more elevated authentication for certain actions, like for example use of Bank ID authentication when approving a payment. In this case the Bank ID authentication will not be displayed by default on the sign in page.
Besides applications which only accept Bank ID type of authentications, all applications should accept your Single Sign-On set up with your SAML 2.0 Identity Provider, but this is not visible on the sign in page unless you type in the email and then go Next.
In case the application your users access has certain sign in options displayed by default which you disallow, then after typing the email, your users will get straight away redirected to your SAML 2.0 Identity Provider.
In case you disallow a certain Identity Provider and your users access an application which requires that and there is no other option available, then the users will get a screen saying "Access denied due to application policy. Please contact your administrator”
Password
Inside your policy you can define your own Password policy rules.
You have the default password policy rules applied when you open this section and you can anytime reset back to the default password policy rules by using the button “ Reset to default“.
If you do changes and do not press Save, there is no impact on your users.
Once you save your changes, you will get the following message:
In case your policy disallows the Visma Identity Provider, this section will display this information:
2-Step Verification
If you toggle on the checkbox for “Require 2-Step Verification during signin“ you are able to enforce all the users from your registered domains to enable 2-Step Verification after they sign in with their email based username and password ( so it will apply only after using the Visma Identity Provider) . The user will get the 2-Step Verification wizard after entering the password.
If a user already has 2-Step Verification enabled, the wizard will not show up and he will get prompted for the 2-Step Verification input based on the state of "Remember device for 30 days”.
If you disable the 2-Step Verification checkbox from your Policy settings, this will not disable the 2-Step Verification on each user which was forced to enable it before. The users will still have the 2-Step Verification enabled, but they will be allowed to disable it from their Account Settings.
In case your policy disallows the Identity Provider Visma, then the 2-Step Verification section of your policy will display this information:
Networks
In this section you can setup allowed network based access for the users from your registered domains.
Once you save your allowed network based access, the users will not be able to sign in anymore unless they are on the allowed network: IP ranges, IP addresses or CIDRs . These must be public IP addresses and not local or private IP addresses.
Note: If your username email domain is on the registered domains list for which this policy applies, please make sure to check your IP ( displayed in this section) to not lock yourself out.
Any user signing in from another IP or network than what you would set as allowed above, would get this “Access denied“ message:
Countries
In this section you can define Geo-IP based Country access. By default, any country is allowed, meaning nothing is set in this list.
If you choose certain allowed countries as access, then the users from your registered domains will be able to sign in if their IP based resolved country is in your allowed countries list.
For example, all from Norway or Sweden would be allowed if you choose these 2 countries:
Any user signing in from an IP which resolves to other country than Norway or Sweden would get this “Access denied” message:
Sessions
In this section you can define:
The number of concurrent sessions, meaning active sessions in the same time from different browsers or devices, which your users from your registered domains can have at a certain point in time. Default value is 10, you can choose between 1 and 20.
You can decide if the users from your registered domains should get logged out if their IP changes while they have an active session.
Applications
You can manage which applications can use the Single Sign-On (SSO) feature in your organization's setup. There are two lists you can use to do this: Allowed Applications and Excluded Applications, within the Policies of the organization or tenant where the SSO is configured. Please note which autotative domains the current setup has in order to not lockout users.
Allow/Exclude applications is left empty
The SSO applies to all applications for any verified authoritative domains in this setup, and the policy does not exclude any application. If an application needs to be handled with a different SSO option, it must be managed in a separate tenant. In that tenant, the specific SSO option must be explicitly configured for the application as an allowed application if it is excluded in the current setup.
For example, if there are 2 Authentication Settings setups and all application are allowed by default, nothing is excluded, then the SSO options are both available to sgin in into any application.
Exclude Applications
If you add an application to the Excluded Applications list, users won't be able to use the current SSO option to sign into that application. For instance, if you have a sign-in option for Admins in an organization/tenant, but "Account Settings" is on the Excluded Applications list, users won't see or be able to use the SSO option when accessing the Account Settings app. The SSO will still function for applications not on the excluded list.
Additionally, if your current setup includes authoritative domains and you set applications as excluded, users won't be able to sign into the excluded applications unless there is another tenant with an SSO setup specifically allowing those applications. In this case, only the SSO configured in the other tenant will be usable for signing into the excluded app.
If you add an application to this list, users won't be able to use the current SSO option when trying to sign in to that application. For example, if the sign-in option for Admins is set up in an organization/tenant but "Account Settings" is listed as an Excluded Application, users won't be able to see or use the SSO option when accessing the Account Settings app. The SSO will still work for any applications not on the excluded list. Furthermore, if the curreent setup has also Authoritative domains and you set excluded apps, the users won’t be able to sign in into the excluded app unless you have another tenant with a setup for SSO applicable for the excluded app -set as allowed in that other setup . In this case only that SSO is usable for the app sign in.
Allow Applications
When adding an Application into the Allowed list then the SSO option is available and usable only for the allowed application(s) as sign in option
Handling Exclusions with Alternative SSO : If another SSO option should apply to an excluded application, you'll need to set up the SSO in a different organization/tenant, where this application is specifically marked as an Allowed Application. Otherwise, users won't be able to sign in to the application. For instance, if "Account Settings" is an Allowed Application in a setup where the SSO option is "Sign in for Employees," users from the registered domain can only access Account Settings using this specific sign-in option. Because of the Allowed List, the SSO option is usable ONLY for the sign in to the allowed application Additionally, if the Allowed Applications list is empty, then the second SSO option will be visible to all users from the verified domains where the SSO is set up, for any application.
Note: If there is only one SSO option available for an application and the Connect IDP is disabled in the authoritative domain policy, users will automatically be redirected to use your SSO.