We use LDAP and our local SQL Server databases to authenticate our users, using Apache Shiro as the app is developed with Apache ISIS. Users in the SQL Server database are REST consumers, while LDAP contains only business users. Lastly, I was instructed to move my LDAP users to MS AAD.
Is there an architecture that allows me to keep both users? Business users will access the app through the MS OpenConnect portal. At the same time, other applications can continue using DB authentication to consume REST APIs.
Yes, it's possible. Actually, the essential of your questions is "how to enable multiple authentication manner s in web app". Since AAD authentication is claimed based, very different from LDAP, so you will need to change your code for sure to upgrade from LDAP to AAD.
Regarding multiple authentication, I don't know the platform you're using. Here is an sample for ASP.NET CORE for your reference:ASP.NET Core: Supporting multiple Authorization
Related
So, we have made a web application login protocol via which users can query a database on Azure SQL Server with sensitive data. Now partner-organizations want to use the same app to query their own databases on their own Azure SQL Server.
Is there a way where we can ensure that as admin + host of the web application we don't have access to their sensitive data, while we are able to send user from the correct Identity Provider through.
Until so far I found the OAuth 2.0 Token Introspection, specifically this implementation: https://wiki.surfnet.nl/pages/viewpage.action?pageId=23794471. Is there a way to implement this within Azure around the Azure SQL Server (if needed via a very simple API)?
Azure built-in reader role:
View all resources, but does not allow you to make any changes.
EDIT: If the problem is security you need to solve it through security countermeasure like Always Encrypted:
This provides a separation between those who own the data and can view
it, and those who manage the data but should have no access -
on-premises database administrators, cloud database operators, or
other high-privileged unauthorized users.
We are using the ADFS activity report to migrate our applications to AAD. Everything shows as Ready and when we click on the Ready link, the text says "We've detected on-premises settings for this relying party that can be migrated to a new Azure AD enterprise application. We'll map the fields and create the new application, but users won't be redirected to it until you say so." By the last statement, it seems like the application is automatically created now. Is that the case? If so, how long does it take to create the application and does it keep the same name as in ADFS?
• The message that you encountered “We've detected on-premises settings for this relying party that can be migrated to a new Azure AD enterprise application. We'll map the fields and create the new application, but users won't be redirected to it until you say so.” Means that the application is a SaaS application available in Enterprise application gallery in Azure AD. This does not in anyway mean that the application has been created automatically, it just means that the application is ready to be migrated to Azure AD and is fully available as a SaaS application in Azure AD gallery and doesn’t need any further relying party configuration migration from the on-premises ADFS server.
• Since the message is displayed only for SaaS apps readily available in Azure AD gallery and are equally configured as a relying party trust in ADFS, its configuration information is readily migrated through the ADFS Connect health application to Azure AD and it can be configured in the cloud itself with admin account access needed for the SaaS application’s account for SSO and SAML authentication configuration required through Azure AD.
You can find the image below for your reference, it shows the ‘Dropbox’ application as ready for migration from ADFS to Azure AD: -
Through the above option enabled, you can easily configure your application’s SSO configuration in Azure AD. If all the configurations are up and running, it will happen instantaneously within a few minutes of time.
Kindly refer to this link for more information on migrating federated apps from ADFS to Azure AD: -
https://github.com/AzureAD/Deployment-Plans/tree/master/ADFS%20to%20AzureAD%20App%20Migration
I think the report is still in preview and it is missing a create application button.
All the documentation only shows the reports & not the create process.
Also this migration tool, is a repackage of the powershell test commands:
https://github.com/AzureAD/Deployment-Plans/tree/master/ADFS%20to%20AzureAD%20App%20Migration
So I assume you need to create the application manually based on the report.
I am fairly new to Active directory and trying to understand it especially from application roles perspective.
I understand the use of Active Directory for authenticating internal corporate users and to implementing SSO across different applications.
What I am trying to gather are scenarios where Active directory can be used for application security ? Is it limited to creating domain users for application to use when interacting with other applications or are there other scenarios where it can be used ?
Example, in below diagram AD DS server has been added to the application landscape for 'computer objects for the failover cluster and its associated clustered roles are created in Active Directory Domain Services (AD DS)'. What does it really mean ?
Azure Active Directory (Azure AD) provides secure and seamless access to cloud and on-premises applications. Users can sign in once to access Office 365 and other business applications from Microsoft, thousands of software as a service (SaaS) applications, on-premises applications, and line of business (LOB) apps. Besides, enabling single sign-on (SSO) across applications and Office 365 provides a superior sign in experience for existing users by reducing or eliminating sign in prompts. For the details, you could read here.
And Azure AD Domain Services provides managed domain services. You can consume these domain services without the need for you to deploy, manage, and patch domain controllers in the cloud. Azure AD Domain Services integrates with your existing Azure AD tenant, thus making it possible for users to log in using their corporate credentials.
For the details about Azure AD Domain Services, please read this doc.
We currently have a WinForms application that accesses our SQL Server database through Entity Framework. The solution was built with database-first methods. Our database is hosted in Microsoft's Azure SQL services.
We need to secure the application connection to the database but the application will reside on employee laptops that need to work from anywhere. Currently the firewall is open to any IP because obviously the IP address for employees change depending on where they are located.
We need to introduce a web services layer but I don't want to run an entire website just to provide a web service to authenticate against. Creating an entire MVVC between the database and a web service, configuring packages, authentication, etc. just seems a bit much just to wrap the EF / DB communication with AD authentication.
How can we add a web service layer that is seamless for Entity Framework that will allow for Azure AD authentication? Is there an Azure service that works with EF to provide SQL Server access with better authentication? What options are out there that we don't know about?
Update: Adding a little to narrow down the question...
Is there a solution or Azure service that can provide a secure web service layer between EF (easily) and our SQL database? For example, does EF work with Azure Web Apps or Azure Mobile Apps without needing separate models for the web services layer?
Thanks in advance for any help.
You can use token-based authentication as explained here and here.
A file-based authentication is also available as explained here.
We currently have a two-tier enterprise application where a Windows desktop app connects directly to an SQL Server database. Data access permissions are set in the database using standard SQL Server features, sqlserver windows authentication is being used (users use their domain logins).
We would like to introduce an application server layer, but we need the same authentication scenario, i.e. all the queries, initiated by the desktop app, have to be run in the database under user domain account that started the app.
It is also important that users do not enter their credentials in the app, the current domain account is used.
Client application is a WPF .NET desktop app.
Is this possible using ASP.NET WebAPI as an application server?
If you're using Active Directory to authenticate users, once they've successfully authenticated into your application, you will have their domain identity. You could then pass that as a part of the connection string for every user-specific database CRUD operation.
I would recommend that you have a shared SQL login though for core things such as caching, database logging and auditing, error logging, application authentication and authorization, etc.