I am looking for a feature in Azure similar to AWS Security Token Service (STS) Temporary Security Credentials to allow federated users access Azure services. We are having support for multiple Identity Providers in our application(Amazon account, Microsoft Account, LinkedIn, Google, Facebook, Github & Twitter). We plan to add support for more Identity Providers in the future.
Once the user logs in using one of these Identity Providers, we want to allow access to various Azure services on behalf of these users. AWS has an option to provide temporary access token on behalf of federated users residing in an external Identity Provider(IDP).
Does Azure AD has any similar feature where it generates a token based on an existing token(from external IDP) and allows access to Azure Services?
Thanks
Gaurav
I'm not sure if it exactly meets your needs, but have a look at Azure Role-based Access Control.
Related
My Azure web application will have both internal and external users. The requirements regarding authentication are:
Internal users authenticate with their domain accounts (with SSO)
External users authenticate through Azure AD B2C (we need to create accounts for them)
How can I set up such scenario?
Regards
George
If your internal users are using Azure AD - simple - you add your corporate AAD as Identity provider to your B2C.
There are various ways to do this. So start here.
If your internal users do not have Microsoft 365 (Azure AD), and you only have on-premises AD DS infrastructure - ... move to Cloud, things will be so much easier. If not, you need at least ADFS, then you can hook up ADFS as Identity Provider in your B2C.
There is no way to make Windows Integrated Authentication and Claims Based authentication at the same time for the app.
We have a client that owns two separate Azure Cloud tenants: ACloud and BCloud.
ACloud contains their regular SaaS and Azure AD users log in with userName#clientACloud.onmicrosoft.com
BCloud contains only IT/sysadmin users managing cloud PaaS resources and users log in with userName#clientBCloud.onmicrosoft.com
We have deployed an API to BCloud which requires Azure AD authentication. The API is being called from a mobile app written in React. There, users are presented with a login screen and must login using username#clientBCloud.onmicrosoft.com
However, we want users to be able to log in using their normal userName#clientACloud.onmicrosoft.com
Is there a way to configure the API in BCloud to use ACloud’s Azure AD for authentication to an API hosted in BCloud?
One resource from Microsoft recommended using the graph API. I think the graph API would allow the mobile app to authenticate the user’s ACloud account, but that SAML token won’t work against BCloud’s API. We are looking for some way that the API in BCloud can accept user tokens from ACloud, so I suspect there is some configuration we need to make in BCloud to trust ACloud’s Azure AD.
Thanks in advance!
I am trying to create a multi-tenant application in Azure AD, which can login all users like Microsoft live/hotmail and also get the access permissions to access their management resource apis. I can get work accounts from other domain login but not live account. I get this error-
User account 'mitesh_***#live.com' from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application '382dfccb-33af-4567-90cd********' 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.
I have heard of MSAL v2 endpoint to login both type of accounts, but I heard that this endpoint doesnt support permissions to access Resource management libraries yet.
Is there any way to achieve this with ADAL or any other way?
Thanks,
Mitesh
The azure ad v2.0 endpoint supports both personal Microsoft accounts and work accounts from Azure Active Directory . But the v2.0 endpoint issues access tokens only for:
-The app that requested the token. An app can acquire an access token for itself, if the logical app is composed of several different components or tiers.
-The Outlook Mail, Calendar, and Contacts REST APIs, all of which are located at https://outlook.office.com.
-Microsoft Graph APIs. You can learn more about Microsoft Graph and the data that is available to you.
v2.0 endpoint doesn't support management apis .And azure ad v1.0 endpoint it supports work accounts unless Microsoft accounts are added as an external user in the tenant first . In my opinion , currently there is no other ways or workaround to achieve your requirement .
My organization has our own custom software solution hosted as a Web App in Azure. We are utilizing Azure AD for our authentication security. Some of our customers may have their own Office365 AD tenants, and so we take advantage of the B2B capabilities to invite these users to our apps and have some visibility of their accounts in our AD tenant (as external users).
We have one customer who would like for us to integrate with their Shibboleth service. We would like to support using their Shibboleth service as the identity provider for their users, and allow their MFA settings to be honored. We don't want to force them to create new identities in AD. What would be needed on our side to support this sort of trusted federation with Shibboleth? Ideally we'd like to be able to see their identities surfaced as external users in our AD tenant so that we're using a single security model for our app.
Azure AD's only equivalent for "trust" or "federation" with others is, as you've been doing, via B2B. Currently there is no B2B-like equivalent that supports direct federation to non-Azure AD IdPs.
However it is possible to set up Azure AD so that it leverages a third party IdP as its primary auth mechanism.
You should be able combine these two approaches to achieve what you want.
Have your customer sign-up for Azure AD
Have your customer configure Shibboleth as per the steps in this article: https://msdn.microsoft.com/en-us/library/azure/jj205456.aspx
Add your customer's users to your Azure AD via B2B as you've been doing for everyone else.
I find the authorization flow confusing for calls to Azure's management APIs, i.e. not Azure API management which is the API gateway SaaS, and I'm hoping for some clarification.
From documentation at https://msdn.microsoft.com/en-us/library/azure/dn629581.aspx:
Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both systems. This was done by having all the Azure properties trust Azure AD for authentication, having Azure AD authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. As a result, Azure AD is able to authenticate “guest” Microsoft accounts as well as “native” Azure AD accounts.
and http://blogs.technet.com/b/ad/archive/2014/08/15/prepping-for-new-management-features.aspx:
Your Microsoft Azure subscriptions uses Azure Active Directory to sign users in to the management portal and to secure access to the Azure management API.
The documentation leads me to believe the Azure AD tenant associated with a subscription acts as a STS with management API being the RP, or authorization server and resource server respectively using OAuth terminology. The tenant can also choose to trust third-party STSes, e.g. another tenant or Microsoft Account services, and thus allow for users from external identity providers access to the management API.
The blog post also writes:
Azure will soon require administrators to be registered in Azure Active Directory to be able to sign in to the Azure portal or use the Azure management API.
Disassociating an admin's account with the subscription's Azure AD tenant, irrespective if it is a "native" account to a tenant or a federated account, should in my mind revoke their access to the management APIs.
I tried validating the assumption using one my subscriptions and couldn't quite make sense of the result. Let's say the subscription has three admins:
Service admin SA using a federated Microsoft Account
A co-admin CA-AAD using an account "native" to the tenant trusted by the subscription
A co-admin CA-MSA again using a federated Microsoft Account
With all three accounts registered with the tenant, any of them can manage resources belonging to the subscription as well as use an web application that in turn access the Insights API through user impersonation.
Removing CA-AAD from the tenant disallowed the account from managing resources and accessing the Insights API once the cookie/access token had expired. This is the expected behavior, except the now non-exitant account still remains listed as a co-admin for the subscription.
However, removing CA-MSA from the tenant did not prevent the account from managing resources or accessing the API. This behavior even persisted between sessions and the account remained listed as a co-admin and not quite the expected outcome.
And now onto the questions:
Why is CA-MSA allowed continued access to management APIs despite it not registered with the tenant?
What is the authorization flow for accessing the management APIs?
How are accounts mapped to those listed as co-admins for a subscription?
Azure subscription refers only two directories for authorizing the users for accessing the management API.
the Azure AD to which the subscription is associated to.
Microsoft AD(MSA).
When a user with Microsoft Account is added as a subscription co-admin, user is indirectly registered in the Azure AD to which the current subscription is associated to. If the user is deleted from Azure AD, it still has the subscription access. It is because the user is still present in Microsoft Account AD.