I am looking to design an MFA policy in B2C that has a longer refresh token window (let's say 1 day) to avoid frequent MFA challenges, but have an elevated access portion of the application that requires more frequent MFA challenges because of the nature of the operations.
According to https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-user-flow, it appears I can accomplish this by creating 2 B2C custom policies with different refresh token timeouts and set the session behavior to Policy.
Policy - This setting allows you to maintain a user session exclusively for a user flow, independent of the applications using it. For example, if the user has already signed in and completed a multi-factor authentication (MFA) step, the user can be given access to higher-security parts of multiple applications, as long as the session tied to the user flow doesn't expire.
My questions:
Is this the appropriate design to accomplish the goal or is there a more preferred approach?
Will this result in a user being double-MFA'd if they log in after 2 days of inactivity and immediately navigate to the elevated portion of the application? I think the answer is 'Yes', but want to confirm. Is there a way to avoid this double-MFA and have the policy recognize that an MFA was already triggered within its own window?
You might try setting Single sign-on configuration to Application and use the same with your 2 custom policies. This will allow the user SSO to be shared for any policy being used and should allow session expire time to be controlled by each one of them. Also, if user has passed MFA authentication it should not need to do it again.
Related
Now I have configured B2C tenant with Enterprise app with MFA with "User flow", confirmation with email.
Everything is ok, but we need to use this Mfa just once per day, so when users will log in in the morning they have to use their login, password, and email to get a verification code just for the first time, and the rest of the day when they log out and log in again they should use just login (username) and pass.
So, how to configure MFA for this?
I saw "Sign in frequency" in conditional access settings, but the documentation wasn't much helpful.
Any advice will be helpful, thank you.
we can manage authentication sessions with azure ad conditional access by configuring below options.
Configure sign-in frequency
Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. You can set the value from 1 hour to 365 days.
Configure persistent browser session
This setting allows users to remain signed in after closing and reopening their browser window. We support two new settings: always persist or never persist. In both cases, you’ll make the decision on behalf of your users and they won’t see a “Stay signed in?” prompt.
You can find more information here as well as steps to configure sign-in frequency.
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime#user-sign-in-frequency-and-multi-factor-authentication
I was wondering if anyone has some real-life information on Azure B2C performance in production with thousands of customers registered. We got a task to create a new system based on an old one which contains 100 000+ customer profiles. As such we would like to use B2C to store and query profile data.
How is the B2C performance for up to 100 000 profiles when it comes to:
JWT-token generation and validation
Using graph api to filter on built-in and extended fields (especially string filtering like startsWith)
If the filtering performance is poor for such many profiles, is there a way to increase it? Like a way to group profiles via some tag info or similar?
Have a look at Azure Active Directory B2C service limits and restrictions.
The following end-user related service limits apply to all authentication and authorization protocols supported by Azure AD B2C, including SAML, Open ID Connect, OAuth2, and ROPC.
Category
Limit
Number of requests per IP address per Azure AD B2C tenant
6,000/5min
Total number of requests per Azure AD B2C tenant
12,000/min
The number of requests can vary depending on the number of directory reads and writes that occur during the Azure AD B2C user journey. For example, a simple sign-in journey that reads from the directory consists of 1 request. If the sign-in journey must also update the directory, this operation is counted as an additional request.
EDIT:
Also, see this:
Azure AD B2C is a customer identity access management (CIAM) solution capable of supporting millions of users and billions of authentications per day. It takes care of the scaling and safety of the authentication platform, monitoring, and automatically handling threats like denial-of-service, password spray, or brute force attacks.
This quote, taken from What is Azure Active Directory B2C?, shows us two things:
Performance shouldn't be an issue
AAD B2C is an identity solution, not a user profile solution
i don't have a bench, but for sure you should check the service limits here: https://learn.microsoft.com/en-us/azure/active-directory-b2c/service-limits.
Those for sure would impact the "JWT Generation" since this happens inside a user journey and every interaction with the underlying tenant counts as a request. The "JWT Generation" performance could also vary depending on your user journey complexity: if you are using the Identity Experience Framework to create a custom User Journey, every Orchestration Step will take time to execute so your users will wait for the journey to complete prior to getting a token. So more Orchestration Steps equals more waiting time, especially if you use Restful Technical Profiles which involve third-party services.
I don't get the "JWT Validation" part: AAD B2C doesn't validate your JWTs, it just issues them. Your application or API should validate them.
About the Graph API queries, the performance are usually good. You're using the underlying AAD tenant which is an enterprise-grade service so such queries are pretty common. Doublecheck if the fields you want to filter on support the function you want to use since not all fields support all the functions. Also keep in mind that even the Microsoft Graph API has limits: https://learn.microsoft.com/en-us/graph/throttling and you should keep them in mind.
If you plan to use your AAD B2C tenant as a database and continuously query it for extracting info, probably you're using it wrong.
Regards, F.
We have received a requirement from client where they want MFA to be imposed mandatorily incase a user accesses certain sensitive applications. Ex., I login to myapps and am prompted for MFA and land on the desired page. On accessing a certain app from myapp I should be again prompted for MFA(irrespective of how long it has been since I logged in).
With conditional access policies, though I attach 'Require MFA' on those applications, it doesn't prompt for MFA if I am already logged in and have a session.
Any pointers as to how to achieve the intended functionality?
I don't think you can achieve this, if the session of the user is existing, it will not re-enforce the MFA auth.
So if you want the re-auth with MFA, you must need to clear the session, the closest way is to leverage the sign-in Frequency policy, but you can only set it to 1 hour at least, after one hour, the user will be prompted to sign in again. Before enabling Sign-in Frequency, make sure other reauthentication settings are disabled in your tenant. If Remember MFA on trusted devices is enabled, be sure to disable it before using Sign-in frequency.
We are developing an application that uses Azure Active directory for sign-in process. Azure AD is configured with MFA(multi-factor authentication). Now we are facing an issue with QA automation where we need to manually update the MFA code. Is there any way to get it done automatically or some other alternative for this.
Generally automated processes require a bit more work when MFA is involved.
You have 2 options that I can think of right now:
Don't use a user account, use a service principal/app registration + application permissions
Allows you to use client credentials to authenticate, no MFA
Run the authentication flow once with a user to get access token + refresh token, use refresh token to get new tokens whenever needed in the automated process
You will get a new refresh token as well every time you use a refresh token, be sure to replace the one you have with the new one
Refresh tokens can and do expire, so you may need to redo the initial authentication again
Take special care in storing the refresh token securely
We implemented the second case for a customer's background process: https://joonasw.net/view/adding-opt-in-feature-to-azure-ad-app
Oh, and in case you are talking about UI automation, the Azure AD product team has said to me many times that you should not try to automate the login page itself.
It has invisible checks and may block your automated login.
In these cases, you may need to have a user with no MFA, use the ROPC flow to get tokens, and somehow inject those tokens to your UI.
Or use the refresh token approach to get the tokens and then inject them.
I wanted to know if there are provisions in SAML based Single Sign-On wherein I could authenticate using token provided by IdP and then once authenticated the authorization i.e. what roles/privileges the user has must be handled at the application end. This is entirely from an Azure Active Directory perspective.
Provisions in SAML based Single Sign-On
If users exist in your IdP but are not in your instance, SAML user provisioning can automatically create the users in your instance's User [sys_user] table.
SAML user provisioning is supported for SAML 2.0 Update 1 when
Multi-SSO is enabled.
How SAML user provisioning works
When SAML user provisioning is enabled and the system encounters a new user that is not in the instance, the instance automatically creates a record in a temporary table with the name u_import_saml_user_, where is an automatically generated text identifier. The system also creates transform map that specifies the data relationships between the import table and the User table. Each IdP in identified in the system has its own transform map. The transform map is created once for each IdP. Administrators can update it as necessary.
When the user logs in, they access an IdP to log in.
The system presents a list of all IdPs that are able to use SAML
user provisioning. If there is only one IdP that can use SAML user
provisioning, that one is used automatically.
If none of the above conditions are true, the system uses the
default IdP.
Administer SAML user provisioning
To update the User table with the users in your IdP, you must first set up field mapping and then enable user provisioning through Multi-SSO IdP settings
Roles/privileges
For roles privileges and User administration you could refer here
Some Benefits of Provisioning
Implementing Just-in-Time provisioning can offer the following advantages to your organization.
Reduced Administrative Costs: Provisioning over SAML allows customers to create accounts on-demand, as part of the single sign-on process. This greatly simplifies the integration work required in scenarios where users need to be dynamically provisioned, by combining the provisioning and single sign-on processes into a single message.
Increased User Adoption: Users only need to memorize a single password to acces
s both their main site and Salesforce. Users are more likely to use your Salesforce application on a regular basis.
Increased Security: Any password policies that you have established for your corporate network are also in effect for Salesforce. In addition, sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data.
To know some more idea You could also have a look on here
Some key resource for your reference
Configuring Azure AD as a SAML IdP
SAML Guide Line
How does SAML work? IDPs & SPs
SAML terms and their purpose
Hope It would guide your way around regarding SAML implementation. Thank you very much.