I saw a post today on linkedIN to say Azure B2B now accepts Google IDs (e.g. people with a Gmail account)
It said this is achieved via Federation, (using google as the identity provider)
As far as I am aware you have been able to do this for a while (or was that because it was in public preview), whereby someone could enter their gmail account but in the background (after the simple on boarding process was completed) this gmail account is linked to a place holder Azure AD account (represented by a GUID).
So in the announcement of Azure AD now accepts google IDs, is this the case where a preview service is now main stream ? or is this something new?
My main question is below
As far as I understand federation (please correct me if I am wrong) although your own Identity provider together with your own STS (secure token service, which is trusted by the replying party) provides you with a token (signed SAML/JWT) with is then presented to the replying parties STS (which then creates is own token from the information in the token you provided), you still need an instance of an object (user/group etc) in the Replaying parties system to check if said instance is allowed access to a resource based on the token (looking at the ACL on the resource and the information in the token). So although the replying party does not need to maintain the users password to authenticate them (done by the trusted Identity Provider) an instance of an object still needs to be created/exists on the Relaying Party system (to match the token information e.g. group membership for example) to the ACL on the actual object trying to be accessed
is the above correct?
Thanks very much
A User is always created in Azure AD, as it is in this case as well.
This applies to users created in Azure AD, synced from on-prem AD, invited from other AAD tenants, personal MS accounts, and now Gmail accounts.
Before Google B2B, if you invited a Gmail user, a personal Microsoft account would be created for them in the background, which would then be added as a Guest in the AAD tenant.
Now if you enable Google B2B, when you invite a Gmail user, they'll log in on the Google login page instead of the AAD login page.
So now instead of creating an MS account invisibly, the Google account itself is added as a Guest User, and AAD relies on Google to authenticate the user.
Related
I have an application registered in Azure Active Directory. I use this app registration to provide a simple SSO implementation for my web application. Users go to my application, choose SSO for authentication, redirect to the login.microsoft.com page, then get sent back with the proper codes. No sweat.
The SSO part is not issue inside or outside of my tenant. I've been able to get the proper flow setup and if users are permitted access, they can login with their Microsoft account and access my application.
Email, however, is turning out to be a real issue.
Internal users in my tenant are not a problem at all. Once I get the JWT from Microsoft, I can request an access token for Graph, send emails, create drafts, delete, etc. There is no issue here.
The problem comes up when I have a user in an external tenant. They can login just fine and get a code from Microsoft, but email doesn't work. I started researching a multitenant solution with the Graph API and made some progress there. I was able to change how they request their tokens using 'client_credentials' and got the appropriate delegated app permissions set up but those permissions allow the external tenant to send emails as though they were users in my tenant. Which obviously I don't want.
I have the external users setup as guest users in my tenant. I've even gone so far as to put an Exchange Online license on the guest users account.
This is the latest error I've received:
[error] => Array
(
[code] => ResourceNotFound
[message] => Resource could not be discovered.
[innerError] => Array
(
[date] => 2021-08-09T16:08:41
[request-id] => 76d9c8ad-e2fd-4286-a8d7-5a3bb4ff3ba8
[client-request-id] => 76d9c8ad-e2fd-4286-a8d7-5a3bb4ff3ba8
)
)
I get this when I put the external user's object ID in the request for the sendMail method of the Graph API. If I put an internal user's object ID into that request, the external user can login, get a token, and send mail as that internal user just fine.
So my question is, is this even possible? Can a user in an external tenant login to my app using Azure AD SSO and also have access to send mail from their account within my application? If so, how far off base am I with my implementation?
As it is a multi-tenant application that supports SSO for external users.
As per Dev's Comment,
Not sure in your scenario, you're using Azure AD B2C (not sure it suits your scenario) or B2B and try to simulate accessing multiple mailboxes
Identity Providers for External Identities
External Guest users with personal MS Account can redeem your B2B collaboration invitations.
During Self Service sign-up user flow, personal MSA can be added as one of the Identity Provider.
No Additional Configuration required to make this identity provider available for user flows.
Email one-time passcode: When redeeming an invitation or accessing a shared resource, a guest user can request a temporary code, which is sent to their email address. Then they enter this code to continue signing in.
Email one-time passcode feature authenticates B2B guest users when they can't be authenticated through other means.
When setting up a self-service sign-up user flow, you can add Email One-Time Passcode as one of the allowed identity providers.
Reference link:
Identity providers for External Identities - Azure AD | Microsoft Docs
B2B Collaboration - Understand user tokens in B2B collaboration - Azure AD | Microsoft Docs
Can someone provide a general approach to meeting these requirements? I've spent a bit of time researching these various topics and attempting to implement solutions and I'm surprised at how much work is involved. Hopefully I'm missing something.
How do I invite consumer users to a B2C tenant so that they can authenticate into our application using their social accounts (ex: Personal Microsoft or Google accounts)? The only baked in solution on the Azure Portal I've found uses B2C local accounts. Note that I do not want to use a publicly accessible Sign Up flow.
Presently I'm looking into a custom process that would work by inviting users to a 'local' b2c consumer account and then allowing the user to associate their social account with the local account.
Once users have authenticated (using MSAL v2 Auth Flow w/PKCE), I want to retrieve a list of permissions the user has for our application.
I'm looking into two options here:
(1) use the auth token to verify user against an internal API that, in turn, makes a call to the Microsoft Graph API to get the user's group memberships.
(2) Create a custom claim that serves the same purpose as user groups
Administrative users of our application need to be able to invite additional users to the application.
I've found some articles that point, again, to using custom policies.
Thank you very much!
EDIT #1 -
Looking into using B2C & Microsoft Graph API I came across some decent, and recent, MS Resources:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/microsoft-graph-operations
And this important-to-me statement -> Microsoft January 28th, 2021:
"Although the OAuth 2.0 client credentials grant flow is not currently directly supported by the Azure AD B2C authentication service, you can set up client credential flow using Azure AD and the Microsoft identity platform /token endpoint for an application in your Azure AD B2C tenant. An Azure AD B2C tenant shares some functionality with Azure AD enterprise tenants."
I'll update my post when I find a solution. Thanks again!
You need to use custom policies.
For first bullet point, see my sample:
https://github.com/azure-ad-b2c/samples/tree/master/policies/link-local-account-with-federated-account
You could do either option. For option 1, AAD B2C can call your api which can call graph api to fetch groups. Then embed the info into the token. For option 2, you could write a role value to an extension attribute and return it in the token.
To invite users, you could use the invite sample. Essentially make an app that calls an API to generate these invite links and send those to the users email. The user clicks the link which allows them to complete their sign up.
https://github.com/azure-ad-b2c/samples/tree/master/policies/invite
I'm trying to wrap my head around the limitations of the ROPC authentication flow.
If I set up an Azure app, can I then sign in any user that has an Office 365 account using the ROPC flow, or do I need to add the user to my Azure app first?
In this documentation, Microsoft says that
ROPC supports local accounts only. Users can’t sign in with federated identity providers like Microsoft, Google+, Twitter, AD-FS, or Facebook.
I'm not sure what they mean by "local accounts"? Is that an account that has already been added as a user to my Azure app?
A local account is an account that was originally created in that AAD tenant.
Any invited guest user does not count.
Though I have heard ROPC sometimes working with AD users who have been synced (which are technically not local users), but that depended on the setup.
I've implemented SSO using SAML authentication on Asure AD in my banking application. I have a scenario where I've to let a manager/supervisor log in to approve a transaction. A regular rep would not have authority to approve, the manager would come in and physically login in (keeping the rep's session intact) and approve a transaction and then logout. Is it possible to have multiple sign ins in the same browser instance through Azure AD?
UPDATE - Per what I researched and mentioned by Carl as well, Azure AD does not support multiple users to login in an application in the same browser instance.
Yes, in the same tenant, users with different roles can perform multiple logins in the same browser. Log in to the Azure portal and you can see that accounts with different roles in the upper right corner can be switched back and forth.
These identities have already validated their credentials for this session, and have an auth token. Switching between these accounts now will not prompt you for their passwords again.
Update:
Even if two accounts are in the same domain, they cannot be logged in at the same time. Currently, only two browsers can be used for two accounts in the same domain.
SAML SSO is a form of delegated authentication. The user is authenticated at the identity provider site (eg Azure AD) which sends a SAML assertion containing user identity information to the service provider site. The service provider trusts this information and establishes a local authentication session for the user using the information contained in the SAML assertion. SAML assertions often contain the user's email address but any user identity information may be included.
You can achieve multiple sign-ins on the same browser , Kindly check this link.
iam currently researching how to implement Single Sign On for our WebService.
This is what i came up with so far.
If a customer of our WebService has an AzureActiveDirectory they can log on with their active directory user account to our WebService if we provide the nessecary interfaces for SAML, Oauth2, OpenID or whatever authorization protocoll we chose and azure supports.
The customers could also have their local network Active Directory synced to their Azure AD and use their Domain accounts to log on to our WebApplication.
Customers need to use the myapps.microsoft.com portal to "wrap" authentication.
Once everything is set up correctly the Identity Provider (AzureAD) would provide use with (e.g) an authenticated User Identity.
Here is were my problem begins.
Of course i need to somehow map the identity provided by the AzureAD to a certain Account for our WebService - we cannot simply use the provided identity.
As far as i understand it, you can grant AzureAD the right to create an Account on the target WebService in the name of the user which is currently signing in.
(Its called : enabling automatic user provisioning in the azure management portal).
However, when testing this with the Box, Canvas or Google apps i failed. Either i got an error or in the case of google apps i was just promted to login with my azure AD test account and then asked for a password and username of my google account (i set up SSO as an azure AD trust relation- so this should not happen)
Can someone provide some insights on how to accomplish the following?
Once the user is authenticated by SSO I want to create an account for our WebSerivce and then save the credentials for that user only in the Active directory of that particular user.
So if the user logs in the second time we can check wether there is an account already existing and log in the user with this account.
(I was told by microsoft that this might be possible with Azure Rights Management, but i cannot really find good documentation on that)
Storing the relationship: "Microsoft AD Identity <-> our WebServiceAccount Credentials" on our side is not desired because we cannot securly encrypt the data in a way that we DONT know whats in there. (or there is , and i dont know of it yet)
"Bonus Question":
Can i support SSO for a desktop application too? (Do i need a provide proxy web application or can the desktop app do this directly?)
Please see my answer to a similar question here: asp.net azure active directory user profile data
However - I'm trying to understand if you need something different. Are you expecting your customers to already have a directory and Azure AD accounts (maybe through having Office 365 subscriptions), and use those to sign in to your web app, or does your app scenario require creation/provisioning of user accounts into your customer's Azure AD directory? Provisioning can be done through graph API (as per your link), as long as the admin of your customer grants consent to allow your app to write to their directory. You can find some samples on github, and I recommend you look through https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx and https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx for code samples.
HTHs,
I think, without testing it. That using the Graph API enables me to save custom data for any Directory User effectively enabling my desired functionality.
This is the documentation i found very usefull.
https://msdn.microsoft.com/en-us/library/hh974476.aspx