I am implementing Azure AD and need to utilize SSO. After logging in to the website, the user can open another tab within the same instance and it automatically authorizes this user. If another instance (as opposed to a new tab on the original instance) of the same browser is opened then the user must log in again. I'm sure this is because the instances don't share sessions even though they are the same browser. Is there a way to configure Azure AD to allow sharing of sessions across browser instances? Or is this something that can be set in the browser?
The issue usually occurs if the browser cookie session memory is getting expired. Make sure to enable cache or cookie access in the browser.
To keep the session cookies active across the browser instances, you can try click Yes when it asks if should be kept signed in. Make sure you have not included prompt=login while configuring the SSO application.
You can also create conditional access policy for the persistent browser to keep the session active for the user like below:
Go to Azure Portal -> Security -> Conditional access -> Policy -> New Policy
Select the Users or workload identities like below:
Please note that, Persistent browser works only for cloud apps option, select All cloud apps like below:
For session, select persistent browser and Always persistent:
And hit create and the conditional access Policy will be created successfully:
Select all the options based on your requirement and configure the conditional policy.
The session cookie lifetime depends on the conditional access policy created in Azure Active Directory tenant for which user wants to sign in to and authenticate.
Please note that, to create a conditional Policy Azure AD Premium license is required.
Reference:
Configure authentication session management - Azure Active Directory - Microsoft Entra
Related
I have a web app that uses the Azure Active Directory (AD) login (Microsoft login), where I have a development environment, staging, and production environment.
The AD login works for my development environment, but I am getting an error when I try to use the same login for my staging environment.
The error I am getting is
Your sign-in was successful but did not meet the criteria to access this resource. For example, you might be signing in from a browser, app, or location your admin restricts
I am attaching the screenshot for more details. Any help is highly appreciable.
Best Regards,
Janak Darji
I have tried to enter my public IP under the network tab as an allowed IP but that didn't work.
You can follow steps below to find which policy cause the issue.
Sign-in your azure portal, and click Azure Active Directory.
Find the user, and click it.
Find the sign-in logs.
Then you can find the login record. And Click it to check the Conditional Access. You can find which policy block it.
You can disable all the policy for test.
You are being blocked by a conditional access policy
In your Azure AD you can use the What If tool to troubleshoot Conditional Access policies
The Conditional Access What If policy tool allows you to understand the impact of Conditional Access policies in your environment. Instead of test driving your policies by performing multiple sign-ins manually, this tool enables you to evaluate a simulated sign-in of a user. The simulation estimates the impact this sign-in has on your policies and generates a simulation report.
You can find the What If tool in the Azure portal under Azure Active Directory > Security > Conditional Access > What If.
Before you can run the What If tool, you must provide the conditions you want to evaluate.
The only condition you must make is selecting a user or workload identity. All other conditions are optional. For a definition of these conditions
Hope this helps!
Not sure how to go about the following scenario:
User logs in with SAML using in an Azure enterprise configured application.
User authenticated succesfully.
If user now logs out from Azure -> I can catch this event using the logout url.
However if the user is deleted / removed from the organisation the user is still logged in in my application.
I've implemented similar logic with Oauth and refresh tokens, didn't find an equivalent using SAML.
As of now there is no support in SAML for the user provisioning events performed by the Idp.
In Azure enterprise configured application there is feature for Automate user provisioning and deprovisioning to applications which ensure that the identities in your app and systems are kept up to date based on changes in the directory or your human resources system.
For more information you can refer this link
I have successfully configured qn Azure AD App Registration, allowing a client_credentials based OAuth 2.0 flow to work. This allows a third party application to access Microsoft Graph API. The app has "Calendar.Read" permission. Meaning the app can pretty much read any of the calendars (including CEO's).
I now have a conversation with security. What is out there in the Microsoft world, that I can use to lock down usage of API access via this Application Permission? Is there ability to do things like:
Restrict IP ranges the App can be accessed from?
Restrict users that can access the App? (However in Client_credentials, there is no user context)
Log traffic / activity happening via the App?
The only thing i can think of now is to say the Redirect URL configuration on the app means, no other application can get an access token using the Client_credentials, even if the application id & passkey get compromised
Any advice on further security controls that can be put in place?
Restricting access: You would need to do this in your application. The Client Credential flow doesn't allow for restricting what users as you point out. However there is nothing stopping you from adding user authentication to your application, possibly using a delegated graph auth flow to determine who they are.
IP Ranges: This is not possible currently.
Logging Traffic: This is not possible on the graph side currently, however you could/should log traffic on your applications side.
Redirect urls will not help you because they are not used int eh client credential flow.
In general application only auth (client credential flow) + a broad authorization scope is very powerful, but must be managed correctly. You don't inadvertently want to build a totally new users/permissions model over the top of the graph :)
There are very few options available currently available to offer these controls at token issuance (in Azure AD) or at API access (in Microsoft Graph). However, you can achieve similar results by carefully managing access to the app's credentials. Here are a couple steps you can take (not exhaustive):
App credentials: keep them secret, keep them safe
Use Key Vault. You can configure many of the restrictions you mention for access to data in Key Vault, including IP ranges and which users access. Key Vault also offers auditing of access to secrets. Don't forget to also be careful about which users have management access to the Key Vault (e.g. other users with access to the same Azure subscription).
Use certificates (public/private key pair), rather than client secrets (passwords), to authenticate the app. People tend to manage certificates much more carefully than they manage shared passwords, and developers are much less likely to hard-code the secret into scripts/code.
Be careful and deliberate about which users can manage the app's credentials
This is often overlooked. A user (or another app) who can access existing credentials, or add a new authorized credential to an app can act as the app and (mis)use all the permissions the app has been granted. This includes:
Users (and apps) in the "Company Administrator", "Application Administrator" and "Cloud Application Administrator" directory roles.
Users who are set as owners of the app registration (Application object) and enterprise app (ServicePrincipal object) for the app.
Users (or systems) who have access to the server or service the application resides on (which will have, or have access to, the credentials).
For all of these cases, ensure this is the smallest possible number of users, and they actually have a legitimate need. For users who do need access, wherever possible enforce just-in-time, time-limited access (not persistent access), such as with Azure AD Privileged Identity Management, for time-bound, just-in-time access for Azure AD directory roles and Azure resources.
I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.
I am building a native iOS application and want to use AADB2C as identity provider where users login, signup, reset their passwords etc.
I cannot figure out a way to let users signup with AADB2C (or regular AAD for that matter) without redirecting them to a (customizable, but still) microsoft website. To be perfectly clear: I want to let customers create user accounts on AAD from a native iOS form without redirecting them to a website, preferably via REST request. (Like here under "Create consumer user accounts": https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet)
Can you create users from an iOS app?
Yes, using the Graph API as per the article you showed. You can only create local accounts at this time though.
However you need to be very careful about how you do it given that currently, the ability to create users requires Directory.ReadWrite.All permission, which also allows all other sorts of operations. You should NOT put the client ID and client secret for an app with these permissions in your iOS app. Rather, you would need to create a backend service that exposes an API for your iOS app to call for user creation.
However, more importantly, what you WON'T be able to do is SIGN IN the users without a redirect (which is what the B2C sign up policy does). In order to do this from your own UI without redirects, you would need Azure AD B2C to support Resource Owner Password Credentials Flow so that you can, after creating the user, use this flow to sign them in and get a token.
Note: You would also need to disable Email Verification so that you can leverage the user account right after user creation. You can set this in the Sign-up policy or Sign-up/Sign-in policy via Page UI customization > Local account sign-up page > Email Address > Require Verification > No
Lastly, as an FYI, there's a feature in the works in Azure AD B2C: Customer Owned Domains, which, paired up with UI customization, would allow you to have sign-up/sign-in pages that you can look like your own and have a URL of your own, with no trace of Microsoft for your end users to see.