We have an APIM in front of some backend APIs, used by our frontend application.
User connect to our app using azure B2C. Once connected, a valid JWT is issued in their favor, carrying some information used by our backend services to return some client-specific data.
Now we plan of exposing those APIs, using APIM developer portal, products and subscription keys.
Here's the flow we would like to implement :
A client A, having an account in our B2C tenant, connect to the APIM
developer portal (1).
It can find and subscribe to our product and then provides his developers the fetched subscription keys
Developers can query our backend through the APIM using the provided keys
APIM/backend services identify the used key belongs to client A (2)
Client A data is being returned
It seems like the developer portal is having its own user-store. Even when using the sign up with b2c option, it only extracts the user mail address from the tenant and still prompts the user with a sign up flow.
Can we not ask for a user existing in our b2c tenant to recreate an account on developer portal but allow him to log in using its credentials ?
How to identify a generated key set belongs to a specific user to only return its client-specific data ?
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
We have an on-premises (self-hosted) app which supports sending email notifications to users by providing SMTP mail server settings. Our users are all in Azure AD and are the only users of this on-premises app. Our users want to be able to receive email notifications from this app.
What is the recommended/best practice method for achieving this? Ideally the solution wouldn't require any additional subscriptions or added cost. It would be nice if the sending email address could be branded to match the app service it is coming from.
Here are some options that I've come up with:
Create a new user in Azure AD solely for sending email
Seems wasteful, and we are billed monthly per user
Use an existing user (i.e. my own) to provide authorization to the SMTP server
Rather not tie my own user credentials to this, and will break if I ever change my password
Use an entirely different email account (e.g. gmail?) for sending email
No relation to Azure AD tenant at all, harder for others to manage
Some existing method/service in Azure that is meant for this purpose, if it exists
Here's my idea on your case.
I watched this document, and I found that we can use API Key to initialize 'new SendGridClient', and it mentioned that we can stored this key into azure key vault.
So if you just wanna use azure ad to achieve the goal of protect your local app from unauthorized user, you may try my idea. First, create azure key vault in azure portal, and you could create a new secret to store your SendGrid Api key. Next to create an azure ad application used to achieve authentication, such as 'ROPC' flow(use user account and password to get access token). Now we can set access policy in azure key vault, added the azure ad app and all your user accounts so that every one could access API key via that azure ad app. After that, your app could send email.
I am developing an application that integrates with other business' Azure accounts. My application needs read access to the Azure Monitor service in our customers' Azure accounts. What is the best way to authenticate?
After reading, here's the current solution I came up with:
Have a customer create an App registration in their account. After creating the app registration, they assign the Monitoring Reader role to the application they created. The customer then will navigate back to the App registration and create a Client Secret. The customer then provides my service the client ID, tenant ID, and a Client Secret. My service will use those to authenticate with Azure and call Azure Monitor.
Is this the recommended way to authenticate with Azure as a 3rd party?
I am not sure if it the best way, but indeed it is a feasible way. This way named client credentials flow, you need to use this way to request the access token, then use the token to call azure rest api, e.g. Alert Rules - Get.
When you request the token, you need to specify the resource with https://management.azure.com/, also, you should note v1.0 endpoint is different with v2.0, v2.0 uses scope not resource, for difference details see this link. So you should choose the correct one depends on which version app your customer created.
Besides, correct some of your understanding of azure ad tenant and azure subscription. They are not called Azure account, the Azure monitor is a service in the subscription, the subscription locates in the tenant. The AD app(app registration) also locates in the tenant. You can understand the AD app is higher than the subscription, it is not in the subscription.
We are working on WEB APIs and want to integrate Azure AD for AuthN and AuthZ. We have successfully integrated the same. We have created enterprise applications, custom roles, assigned users for the same.
Now we need to allow access to APIs with AWS like keys (Secret / Access keys). Individual user can generate their own keys and store those in Azure AD so that when those keys are used, user can be authenticated.
I didn't find any way to achieve this using Azure AD. Any suggestions around same are welcome.
Meanwhile I have gone through custom store for keys. Please refer link : https://www.codeproject.com/Articles/1228892/Securing-ASP-NET-CORE-Web-API-using-Custom-API-Key
Thanks in advance.
Azure AD authentication uses tokens.
So any app wishing to call your API must authenticate with AAD and acquire a token for the API.
If these users are making apps within your organisation, then they can register their app in your AAD and require access to your API. They will create and manage their own keys.
If on the other hand these users are making an app for another organisation, you'll have to make your API a multi-tenant app.
And you'll need to have an on-boarding page in your API through which you will redirect their admin/user to the AAD login page, where they will consent to any permissions your API requires.
After this a service principal is created in their tenant.
Then they can register their client apps and require access to your API.
They will have full control which permissions they want to assign to each app, what roles to give to users etc. But of course the tokens will contain their tenant id so you can filter access on that.
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.