Am I mad?
I can create authentication providers using OWIN and ASP.Net Identity for Facebook, google, etc. But I have a requirement to authenticate my users against Windows. I'd rather not require the configuration of AD, or to tell IIS what Domain to authenticate against; I just want the IIS to authenticate as if the settings was Windows Authentication in the Web config.
But then I want to be able to get roles and user details. I want Roles in SQL Server. I also require the user first and last name, which are not directly available from windows auth).
In the past I have done this with a mixed authentication middleware, and grabbed the user details from the principle context when creating the user, store that in SQL, and in the authentication cookie. but this seems a bit of overkill here.
Has anyone succesfully used basic Windows Authentication but held roles and first/last name in sql?
thanks
Yes, you can use Windows authentication with ASP.NET and IIS.
This article, should be a good start.
You can then store users and their AD groups in the application, and manage access based on that mapping.
Related
using framework asp.net core - on .net core MVC jquery
In the account controller, I am attempting to obtain the user currently logged in to that machine on an intranet network. ie the windows authenticated user.
If I try WindowsIdentity.GetCurrent() is just returns the identity of the application pool. not what I need.
I have anonymous turned off and windows auth turned on in both the launchsettings.json and the IIS settings.
I understand that the identity middleware for abp framework I'm using is table based so the Controllers 'User' property is not what I need either.
I am wondering whether this is a limitation of the .net core?
You need to disable Anonymous Authentication and enable Windows Authentication for a specific page like Login page. This way, you say the Login page requires NTLM. So browser sends authenticated user information. And you can retrieve it with HttpContext.User.Identity.Name
Then there's next challenge! Authenticating this user with ABP. For this one, you can check out this StackOverflow post.
Newbie question here on Authentication. I am used to incorporating authentication into my app backend server, like Spring Security Authentication for example. I don't really understand how the authentication providers work.
My concern is that somehow each provider can only authenticate its own accounts, ie google can only authenticate for gmail accounts, and Azure Active directory can only authenticate some kind of Microsoft registered account? I am disinclined to oauth because as a user I am always paranoid about signing in for some game or app from an unknown provider becacuse I never am sure whether I just gave my gmail or facebook account password to a rando.
I am fine giving people the option to use Oath, but less comfortable if that's the only option. I would like people to be able to give me whatever email address they want, and a password which they create for my site only.
Also these questions: If I use an authentication provider can I get the actual email address being used to log in? Or do I only get a token?
If I am going to build my own authentication service so I can accept any email domain as user name, what is the easiest to implement in Xamarin forms, and can somebody point me to a tutorial or something?
Advice appreciated thanks.
Yes, you're right, each identity provider provides the ability to authenticate their own users; Google OAuth supports Google accounts, Azure Active Directory supports Microsoft work & school accounts, Microsoft Account supports Microsoft personal accounts, and so on.
You have quite a few options on how to add support for these identity providers in your app, in addition to what we typically call 'local accounts', or accounts created specifically for the given application. I'll list out a few approaches:
You can write all the code yourself to integrate with each identity provider individually, and build-your-own local account solution as well.
You can use an SDK/library in your Xamarin Forms which facilitates using multiple identity providers within your app. The Xamarin.Auth package has historically served this purpose for Xamarin apps. It provides auth capabilities for Facebook, Google, Microsoft, and Twitter.
You can use a dedicated cloud service which provides authentication services for your app. Some examples include Azure Mobile Apps, Firebase Auth, Gigya, and more. The exact identity providers supported and the level of support for Xamarin/Xamarin Forms will vary across each one. Azure AD B2C is another option that I know supports Xamarin Forms as well as Facebook, Google, Twitter, and local accounts (disclaimer: I work on AAD B2C). These services sometimes have free tiers & paid tiers, so you can compare & contrast each.
You could also build your own authentication service using open source code like Identity Server if you wish.
It definitely depends which route you go, but generally speaking each solution will provide you access to some user profile information upon user authentication. For Azure AD B2C, you can configure the claims that are returned to your application in the tokens your app receives. For other services, you may need to make a REST API call to get some user data like the email address.
HTH.
I have an MVC application (.Net Framework 4.5) which is been there for the last three years and using Forms Authentication mechanism. This application provides different accounts like Personal, freebie, Enterprise etc. For an enterprise account, we are handling everything in the same application. I.e. Suppose an enterprise called “xyz” created an enterprise account with the application, then we are providing a custom URL like “https://application/xyz/login” and from the URL we are identifying that enterprise. I don’t know the exact reason why they implemented like this as I have seen applications that are having enterprise accounts are created as subdomains (e.g. https://xyz.okta.com). Now the client asked to integrate Okta into this application.
So I looked into Okta and found SAML is the right way to do and ends up in KentorIT Authservices. Initially, I was able to integrate this with a sample MVC application and the authentication part was working fine. With some basic idea about SSO, I have started integrating kentor authsevices into my application. The challenges I found in this implementation are:
1) For Enterprise accounts, Okta configuration settings are different for each enterprise and with my current application implementation, it is not possible to set it in from the web.config. So I have tried to set it from code and I was able to integrate those settings by replacing Configuration.Options.FromConfiguration;. I’m planning to store all configuration related things(Single sign-on URL, Audience URI,Identity Provider Issuer" etc.) in the database so that I can get the information whenever I wanted and I’m assuming that “Identity Provider Issuer Id is unique for each Okta account. In an IdP initiated flow, when the user tries to access the application it will redirect to AuthServices\Acs action method and from that, I’m trying to read the configuration settings. From the request is there any way I can identify from which Okta account call came(like Identity Provider Issuer)? Currently, I set the "Identity Provider Issuer" value (and I think which should be unique for okta account) to the Default RelayState field under General SAML settings tab and I was able to retrieve it from AuthServices\Acs action methods. Does it seem to be a good idea? Please advice.
2) The Enterprise accounts are limited based on the number of licenses (say 50). Suppose if the Enterprise Okta admin intentionally added 55 users all those users can successfully authenticate the application based on the default settings. Is there any way I can handle this scenario. Do I need to keep a record of the list of users that came under a particular enterprise account?
3) From the documents I understand that Kentor authentication service is only for authentication and authorization part has to be done from the application itself. The current application implementation consists of a custom authorization attribute which checks for user permissions that are stored in the database. That should be there as it is and we have to do the authorization based on database permissions. Right?
Expecting your valuable suggestions and please correct me if I'm wrong. Thanks in advance.
Don't use the RelayState for sensitive data unless you cryptographically sign it. It is not protected by any signature when using the POST binding, so the user may manipulate it. To get the issuing idp, check the issuer field of any claim generated by AuthServices instead.
Yes.
Yes, that's the whole idea with Kentor.AuthServies: To plug SAML2 authentication into the security model of .NET to allow you to use any current/traditional Authorization setup.
I am trying to understand concepts of windows authentication, forms authentication and their differences. I am confused. Can someone help me in clarifying this.
Thanks.
Windows Authentication provider is the default authentication provider for ASP.NET applications. When a user using this authentication logs in to an application, the credentials are matched with the Windows domain through IIS.
There are 4 types of Windows Authentication methods:
1) Anonymous Authentication - IIS allows any user
2) Basic Authentication - A windows username and password has to be sent across the network (in plain text format, hence not very secure).
3) Digest Authentication - Same as Basic Authentication, but the credentials are encrypted. Works only on IE 5 or above
4) Integrated Windows Authentication - Relies on Kerberos technology, with strong credential encryption
Forms Authentication - This authentication relies on code written by a developer, where credentials are matched against a database. Credentials are entered on web forms, and are matched with the database table that contains the user information.
Windows Authentication refers to authenticating against Windows user accounts on the box that the application is running on.
Forms authentication is a stand alone method of authenticating in .NET forms that you can hook up to some other system, such as a database.
It's pretty simple. Windows Authentication makes use of the Windows Login system.
http://en.wikipedia.org/wiki/Integrated_Windows_Authentication
And with Forms Authentication the user will need to provide a username and password manually.
http://www.asp.net/web-forms/tutorials/security/introduction/an-overview-of-forms-authentication-vb
The Forms Authentication also allows you to choose where you access the login data from. It could for example be stored in your own local database. While Windows Authentication is only going to use your Windows login data. This data usually comes from Active Directory, if your network is built using an enterprise/buisness/domain setup.
http://en.wikipedia.org/wiki/Active_Directory
Windows Authentication-- The user will be authenticated on the IIS server against the credentials he provided when logging into his system. If the authentication fails then a pop up form will be displayed in the Internet Explorer asking for his credentials i.e. username and password.
Forms Authentication-- A default Login Page will be available like Facebook login, where user will be authenticated instead of automatically getting the credentials from the system credentials i.e. the current user of the Windows system. If the user requests a secure page and has not logged in, then ASP.NET redirects him/her to the login page. Once the user is authenticated, he/she will be allowed to access the requested page. Here IIS does not come into effect for authentication, it completely depends on the web application.
We are having a hosted web application and it uses forms authentication.
This webapplication is accessed by users belong to different partner organizations.
Currently users belong to the partner organizations are accessing the application using the credentials that we give it to them.
Now, some partner organizations wants their users to access the application using their active directory credentials.
We are planning to use ADFS for these partner organizations, so the users will be authenticated using Active Directory within their network and claims will be sent to the webapp via the Authentication token cookie set by the ADFS. From the claims, we map the users to the internal userIds of the web application.
My questions are , if we make the web application ADFS enabled,
1)Is it possible to still allow the other partner organization users(who don't want to use ADFS) to login to the web application using the existing login page(forms authentication)?
2) Should every page in the ADFS enabled webapp be accessed through https?
Any solutions or pointers would be much appreciated.
Thanks
-arul
Your app needs to require claims that describe the user, regardless of where they login from. It should not handle authentication in either case; this should be delegated to a trusted issuer, an STS. This will allow it to interact w/ users in a uniform way irrespective of where and how they authenticate. This means that you're going to need to use ADFS in two roles: that of an Identity Provider (IP) STS and of a Federation Provider (FP) STS. For users of partner companies that don't want to maintain users themselves, you'll be the IP-STS; for those that do, you'll be an FP-STS. In the latter case, ADFS will redirect users from your realm back to the partner's site where their IP-STS will authenticate them and send them to your FP-STS. It will map your partner's user ID and claims into ones that make sense in your realm. This and other information about the user will be included in the set of claims that are issued from your FP-STS. As a result, your app, only trusts your STS regardless of which scenario is appropriate for different users. Note that in this scenerio, there will be two STSs: your ADFS FP-STS and your partner's IP-STS, which may or may not be ADFS. In the other case, there will only be one STS: your IP-STS.
Not every page on your ADFS Web app needs to be accessed via HTTPS; however, everyone that's used in the authentication process should be.
This is really a non-trivial undertaking. If you want to talk about it more, please feel free to get in touch w/ me.