- 03 Apr 2024
- 4 Minutes to read
- Print
- DarkLight
- PDF
Policies
- Updated on 03 Apr 2024
- 4 Minutes to read
- Print
- DarkLight
- PDF
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.