We are trying to migrate a legacy intranet ASP .NET web app from "Forms" based authentication into a "Windows" based one so that the user doesn't have to enter the credentials again after logging into the PC, we just want to read the current logged-in identity and use that for authenticating and authorizing the user in the application.
Doing windows authentication in ASP .NET is pretty straight forward, what i wanted to check though was how the user's and their groups should be managed within AD or ADAM.
The same user can have rights on multiple environments of the same application like Dev, UAT, LT, Prod etc. so the same domain account needs to be authenticated in multiple environments (different URL). Also, once authenticated into an environment the user might belong to multiple roles which decide what actions are available for the user to perform.
I was looking for some recommendations here in terms of how we set this structure up in AD, we are thinking of creating groups in AD for the different environments like App_Dev, App_UAT, App_Prod etc. and have nested groups within each of them for the different roles in the application like App_Dev\Role1, App_Dev\Role2, App_UAT\Role1 etc. for each of the environments and add the users inside it.
What do you guys think?
You have to rememeber that Authentication and Authorization are two different things. You have combined them in your logic.
For example, your authentication mechanism is AD. So yes, use AD for authentication of credentials and group membership to ensure they can authenticate with a specific instance.
However, you can still use the classic RolesProvider and use a SQL backend to store roles and user to roles assignments per instance within the database. This is easy and uses the built-in feature of ASP.NET without having to go overboard with creating groups in AD. You can do various searches on the web about ASP.NET AD Authentication and SQL Roles Provider. I think ScottGu even has an old article about how to do it.
Lastly, what you have described here is not SSO or Single Sign-On, I'll update your question to reflect this. SSO refers to creating a token that is trusted and shared amongst many applications. It doesn't seem like you need that with the example provided, but if you do, you would be investigating ADFS and the Windows Identity Foundation (WIF). Just because you use AD does NOT mean you have SSO, it simply means you have a single Authentication Provider, but you still don't have a token based system that actually only requires an initial Authentication and Authorization request to a central authentication service, usually ADFS.
Related
My enterprise application is developed in .net framework 4.5 and is using windows authentication. In which case, as we all understand, it is the underlying AD(active directory) that authenticates the user.
I have to replace windows authentication with token based authentication, keeping the .net framework 4.6 and AD(active directory). I guess oAuth is a possible solution, could you please share some thoughts on other possible solutions and as how could I get started.
HISTORY
It was common some years ago for apps to be developed for a corporate intranet, in which case Windows Authentication was a good solution. When token based authentication came along the benefits typically were:
Extend reach so that apps could be used over the internet
Support cross domain scenarios, eg APIs in a different domain
Support multiple authentication methods / policies depending on user location and device type
Write less security code and make new security features available to multiple apps
IMPLEMENTATION
An OAuth migration is a major architectural change and needs to be managed in terms of costs and benefits, though once done your apps will be quite cutting edge. Here is how Windows Authentication typically works in an OAuth 2.0 / Open Id Connect world, which requires a more complex setup:
Your UI redirects to a Cloud Authorization Server (AS), such as Azure Access Control
The AS redirects to an identity provider - such as an on premise version of ADFS (Active Directory Federation Services) - that is configured to use Windows authentication
When in the corporate intranet the user is automatically signed in and ADFS posts tokens to the AS
The AS posts different tokens to your UI
Your UI calls the API with the AS token and the API validates it
GETTING STARTED
If you decide that the effort is worthwhile then there are 2 parts to the job. Note that your application code will only ever interact with the AS and doesn't need to know or care about the authentication method:
Infrastructure migration
Updating the code in your UIs and APIs
If it helps, my blog and code samples are designed to help people deal with some of the challenges of OAuth tech. Maybe have a look at my first tutorial to get set up.
I have multiple Azure AD with one application in a different azure server; my application is in spring.
My problem is that my application must work with different companies and I don't find how to add on each company, but with one page of login for all companies...
Azure Active Directory applications can support multiple tenants. You need to make sure your application has the setting: availableToOtherTenants: true.
From there, you can use the common endpoint to dynamically discover which tenant the user is trying to sign into when they type in their user credentials.
This information, and more is in a very apt article titled: How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern.
I hope this helps.
Here is the scenario, I've an instance of Oracle Identity Manager (OIM). The instance stores all of my user profiles. Now, I'm writing few REST APIs, which should be authenticated using users present on OIM.
I'm also thinking of using AWS cognito to provide authentication flow. So, my questions are
Q. How can we connect Cognito & OIM?
Q. If no need of Cognito for this scenario, then how can we make use of OIM?
I've recently strated looking into both the tools. So, please spare me for some obvious questions.
I'm from the Cognito team, and Bruce0's suggestion is spot on. If you need to access AWS resources, you would set up a developer authenticated identity provider which could leverage this (or any other identity manager/provider).
starting a proof of concept for this model it appears not to be possible to configure the membership provider per request to the respective clients database. It appears that the web application instantiates the membership providers on application start and doesn't allow modification to this during subsequent requests.
I have tried using reflection and modifying the connection string in the Application_BeginRequest (in the global.aspx) but it appears that the membership provider is designed and implemented to only initialise once per application rather than per request.
This implies for the separate database approach, the default asp.net membership provider wont work with the single application/multiple database (multitenant seperate database) model.
what authentication/authorization model do people use in this architecture? do they use a custom implementation of the Microsoft membership providers or do they use a different package or library?
Cheers
Tim
In the case of a multi-tenant application development scenario, the best preferred is a SSO or to go with a custom profile management system.
In order for you to enable tenant based authentication using the databases, you can have a connection string manager that identifies your tenant based on some of the criteria like the company code or the URL and then use the user login data from that database for that tenant's users.
The usage will be like you identify / infer the tenant code from the login credentials and then choose the database that is available for that tenant and then authenticate the user against this database. Hence the tenants can have their own databases for their user's authentication.
This is feasible and can also comply with the regulatory requirements that may be for different tenants based on their geography.
My manager keeps talking about how I will be "developing" an Application Express "security module", however from what she told me we need to have, I don't see what there would be to develop, seeing as Apex already has authorization/groups which allow for various groups of people to see various content.
Is there something that I am missing? What does she mean by a "module", or is it just general wording?
APEX provides several different ways to authenticate users. One approach is to use the "Application Express" authentication scheme and just to create APEX users. Another approach is to use the "Database Account" authentication scheme and to create Oracle users. A third option is to create a custom authentication scheme and to implement your own user management functionality.
Application Express authentication tends to be the easiest to deploy for a small application but tends to get unwieldy over time. It's hard, for example, to give an application administrator the ability to create APEX accounts. You can't tie an APEX account in to a single sign-on solution. It's not easy to integrate with the permission management systems that other applications use. If you're deploying an application in a large company, the last thing the security department needs is one more place where they need to create user accounts, manage privileges, de-activate accounts when someone leaves or changes roles, etc.
Database authentication tends to be more scalable than APEX authentication since Oracle database account provisioning is likely already part of your organization's authentication and authorization infrastructure. On the other hand, that still means that you're creating an Oracle database user for every user you want to create in your application which probably involves a call to a DBA (technically, you could create database users from your application, but most DBAs are going to be concerned about the security implications of that). If you intend to create an internet-facing application with tens of thousands of users, database accounts may get unwieldy.
I'd wager that the vast majority of medium to large-scale APEX applications use a custom authentication scheme. That may involve creating a USER table where you store the username & the hash of the password or a query against an LDAP/ AD repository. That sort of approach provides the most flexibility since you can code whatever you'd like into the authentication system. You can hook into whatever custom authentication/ single sign-on solution the organization happens to use. It probably makes creating new users from within the application much easier (obviously depending on how the authentication system is designed).
My assumption is that your manager is expecting that you'll be writing a custom authentication scheme for your APEX applications.