I am a developer working on a think client application. One of our customers wants us to provide hosting for the application and I have set up azure remote app for this. The customer is asking if it will work with single sign on.
From what I can see it can work if I have access to their directory. For example if I could join their domain or change my default directory to be their directory it should work. Is this good practice though? From what I see the only way to do this is give their administrators access to my subscription.
Is there another way?
Azure Remote App offers two deployment options
- RemoteApp cloud deployment enables user logon with Microsoft account or corporate credentials federated with Azure Active Directory
- RemoteApp hybrid deployment enables full access to on-premises network, and user logon with corporate credentials federated with Azure Active Directory
So in both cases, you may have single sign on for your customer application, provided his current identity provider (for example On premise Active Directory) is federated with Azure Active Directory
Hope this helps
Best regards
Stéphane
Related
can someone explain how access management on Azure differs from local on-prem Active Directory - DC? For example, on DC and AD we can have local security groups for application authentication and authorization and for share folders, but how this thing works in Azure for their SaaS and onedrive? Does Azure have the same security groups like AD has? Where can I learn more about this specific architecture?
Thanks!
Yep, it's called Azure Active Directory (AAD). Documentation is here. You can set up groups and policies similarly to how you would in an on-prem AD.
Here's a comparison of the two.
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
This isn't a specific problem question but a "cry for help".
My problem is this. Our organization is in the process of implementing Office365.
Until now there were tens of applications with their own authentication and authorization but in the process most of them will be rewritten to use within O365 environment.
We are facing the problem of creating one endpoint (ASP.NET WebAPI app) which will be used to authenticate a user with his credentials from Active Directory (or B2B AD on Azure because some apps are used outside) and tell if this user is allowed to use app that asked to log him.
I'm just wondering through documentations and sample code but can't decide what will be a good practice in this scenario. Should we just build each app and use Azure Active Directory provider to authenticate. Or is it possible to setup ONE api that will hold all apps Ids and its userIds - then it will check user credentials against AD and give app token/cookie...
My best bet is to try this: http://www.tugberkugurlu.com/archive/simple-oauth-server-implementing-a-simple-oauth-server-with-katana-oauth-authorization-server-components-part-1
But create Provider for AzureAD. But then its still question about this B2B AD part.
Please help by pointing to some up to date resources..
You should register each of your B2B application within your Azure Active Directory and configure them to use AAD as the Identity Provider.
Then you can administrate everything you want (e. g. which user has access to which application) within the Azure Active Directory blade from the Azure Portal.
You are getting this backwards. If you have apps integrated with Azure AD you don't have to create endpoint which will validate users right to use apps but you are assigning right to use an app in Azure AD. This is whole point.
What am I missing here? I'm thinking of moving my data center to Azure. I've created a corporate virtual network that has my ADs, my certificates, basically the family jewels of the company that I'm trying to build in the cloud. I've plugged up every obvious security hole that I can think of except one: the login to the Azure Portal is just a simple user id/password. If someone picked off my Microsoft Live user id, all they need is a password cracker. And a disgruntled or dismissed employee could easily cause havoc. Is there some way to lock down the portal? Does anyone in the security business think these Azure web sites are secure?
You can use Azure AD to properly secure the portal authentication. Azure AD is designed to securely authenticate applications in the cloud and it is supported by the majority of Microsoft solutions like Azure Portal. It will provide features like MFA, access control, self-service password reset, etc.
Although Microsoft Accounts also support some of these features, you can't force your users to specific policies, that's why Azure AD is important for enterprise level security.
Once you create a directory for your company through Azure Portal and synchronize your AD objects with Azure AD using the AAD Connect tool you will be able to login to Azure Portal using your corporate credentials and force users to use Multi-factor authentication or even apply other policies.
Azure Active Directory features and capabilities
Azure Active Directory Hybrid Identity Design Considerations
Integrating your on-premises identities with Azure Active Directory
I'm working on an application that will allow users to authenticate to Azure Active Directory and then manage resources in their Azure account via Azure Resource Manager API calls.
I've found several walkthroughs on building such an app including this post. However, in the part that discusses authentication with Azure Active Directory, there's a step showing the need to manually retrieve the Azure Active Directory name from the Azure Portal.
The directory name is plugged into app settings (and ultimately authentication calls to the directory) as follows
http://login.microsoftonline.com/{directory_domain_name}/OAuth2/Authorize
Is there any way to programmatically retrieve {directory_domain_name} without requiring users to login and lookup the information in the Azure Portal?
The one answer to this question has a dead link and another pointing to the Graph API, which seems to still require the domain name.
For your particular scenario, look like you want to build an app that will be users from different Azure AD tenants. This scenario is best addressed by building a multi-tenant application.
To make your application multi-tenant, you'll need to go to the Azure Portal and in the Configure tab of your Azure AD application, set the "Application is Mult-Tenant" option to yes.
Once you do this, you can just call
http://login.microsoftonline.com/common/oauth/authorize
http://login.microsoftonline.com/common/oauth/token
And Azure AD will resolve the figure out which tenant to authenticate against based on the the credential that the user types in.
More information on multi-tenant applications:https://azure.microsoft.com/en-us/documentation/articles/guidance-multitenant-identity-authenticate/
Sample multi-tenant application: https://github.com/Azure-Samples/active-directory-dotnet-webapp-multitenant-openidconnect