I'm hoping this is possible. Note that I'm NOT trying to mix the two authentication forms. My goal is to have an existing site secured as it is now with Forms authentication. I don't want Windows authentication to work in any existing pages, we use Authorize attributes to secure controllers and that should continue to function as is.
I'd like to add an MVC Area where ONLY Windows authentication will work. I was thinking of creating a new Authorize attribute subclass that will only accept Windows integrated authentication, but I'm not sure how to specify which authentication mode for the site vs. the area.
How would I configure such an application?
Since MVC doesn't use the physical folder structure (except for Content, like scripts, images, css, etc.. and even then in MVC4 much of that is now virtualized in bundles), all authentication is done at the root of the site, more or less.
You would be better off creating a sub-site with it's own web.config and authentication settings rather than trying to do two forms of authentication in the same site.
Related
I think this is the first time to ask a question here, but wanted to try. Hope I got this right. I have searched all over web but nothing seems to come up for this scenario.
On a Test Project, I was going to have a ASP.NET Web API that will be exposed to the web. It will have authentication and authorization. The roles will be managed thru the Web API. I will have a ASP.NET CORE MVC app as one of the clients accessing the Web API.
What I would like to do is pass the users roles (in a Claim?) from the Web API into the Web Site and have the roles be used in the Controllers Authorize as well as in the views (menu filter and button disable functionality). Of course the issue is the separation of the Website from the Web API.
I have seen tutorials where the role is passed to a Angular/React/Vue site but I am trying to see about this in a Asp.net Core website.
I think I want to pass the claim(with the Roles) to the Website and have it use it as if the website was accessing the DB directly.
Just trying to figure out how this would be done.
Any direction would be appreciated.
Thanks
I'm building an application that has a core hub, say it's called musictickets.com
We'll provide a subdomain (bandname1.musictickets.com) to bands on which only their content will display, which they can mask using a CNAME record to be part of their domain - so tickets.bandname1.com
There would be multiple bands using the platform so you'll end up with pages at
tickets.bandname1.com
tickets.bandname2.com
etc.
I'd like a user who registers at tickets.bandname1.com to be automatically logged in on every site that uses the service, including the parent, musictickets.com . They should be able to register/login using OAuth or directly via form based authentication.
I'm looking at SAML (specifically https://github.com/aacotroneo/laravel-saml2) as one option, but want to throw this out to the wider community for comment.
I've also looked at using token based SSO as described here (single sign on (sso) laravel) and running an auth server (which I may do in any case). Alternatively, I've looked at using iframes to provide the functionality which feels quick but dirty.
As I understand it, I wouldn't be able to use cookies (for an API key for instance) because whilst all of the content will be displayed via a subdomain, the CNAME would make it a different domain.
Does anyone have any thoughts on the best strategy?
I have asp.net mvc3 application with forms authentication. But the our client request AD authentication as well. But the mvc3 app is hosted outside the clients network. What are the possible solutions for this.
Get permission to access the clients network from remote server.
Get an API to access the active directory data from webserver.
If we choose opt one how could we access active directory for authentication from outside the client network. I anybody have any idea or better options please let me know. Thanks in advance.
My guess is that the Microsoft security products can support this out of the box but I'm not sure how so I suggest that you direct your question to whoever supplies your client with their Microsoft product support.
If you'd rather build a solution so that you've got more control over how it works a quick search found an interesting approach at https://support.freshservice.com/support/solutions/articles/169196-setting-up-active-directory-single-sign-on-sso-for-remote-authentication where they created a simple ASP.Net web site that used AD authentication for sign-on. MVC 5 can build a WebApi site that does that just by creating a new project in Visual Studio with the right options.
That site wouldn't have to do anything except confirm that the credentials supplied were valid or not. Your application would ask the user to enter login / password details, then send a (properly secured) web request to the authentication site to determine whether they're valid. As long as you keep the communication between your server and the client web service tightly secured this should do what you need without much fuss. That approach removes the need for your server to communicate directly with the client's AD server.
We're developing an API and a single page application (that is one of more possible future consumers of it).
We already started on the web API, and basically implemented a system very similar to the one John Papa made in his course on pluralsight, named "Building Single Page Apps (SPA) with HTML5, ASP.NET Web API, Knockout and jQuery".
We now need to implement authentication and user managing in this application and need to find the easy way out to implement this in as little time as possible as we are in a hurry.
We realized the SPA template included in the ASP.NET update had very similar features to our needs, but we wonder what the best approach to implement a similar feature in our existing code.
We are novice developers, as you might figure.
Is it possible nstall some packages using the package manager, and voila, a simple membership and OAuth auth option be readily available?
Our use case is that we need to protect some resources on our API based on roles, and that one should be able to log in using a username and password, but also log in using ones facebook, google, or twitter account.
Found an interesting talk regarding the subject here: https://vimeo.com/43603474 named Dominick Baier - Securing ASP.NET Web APIs.
Synopsis: Microsoft’s new framework for writing RESTful web services and web APIs is appropriately enough called ASP.NET Web API. As the name applies, this technology is part of ASP.NET and also inherits its well-known security architecture. But in addition it also supports a number of new extensibility points and a flexible hosting infrastructure outside of IIS. There are a number of ways how to do authentication and authorization in Web API - from Windows to usernames and passwords up to token based authentication and everything in between. This talk explores the various options, and puts special focus on technologies like claims, SAML, OAuth2, Simple Web Tokens and delegation.
We eventually went with the SPA template, doing authentication on the API (separate MVC part).
Then the API would generate a unique token and redirect the user to the front-end with the token in url parameters.
The front-end then needs to send this token on every subsequent request.
Have a look here - Identity Server done by the security experts. This is all you need in one package.
In terms of OAuth, you would need to use Client-Side Web Application flow which the access token is issue immediately to the client and can be used.
Out of the box MVC3 applications allow Windows Authentication when using the Intranet project template, or the Forms Authentication for an Internet project template. I've got a site that I'd like to use either. In addition, I've got an existing site that uses it's own custom type of authentication that authenticates users (no authorization or roles, just identification). I may need to use functionality of each, in addition to the data from the legacy system for authentication. Due to this, I'm trying to determine a way to abstract my authentication and decouple it. I'd like to use some kind of dependency injection, based entirely upon configuration, so I could deploy this same site in two different locations, and switch the authentication model (Windows Auth/Forms Auth/ Custom Auth), by changing configuration only.
Currently, all the ASP.NET applications I've worked with, including the MVC3 template projects, seem to be very tightly coupled with the authentication type used.
Am I thinking too far outside of the box on this one?
Is this possible, or is there a reason for this tight coupling?
UPDATE
The real problem I have is between the existing legacy authentication I need to use for some users, versus the Forms Authentication I need for others.
The Windows versus Forms authentication isn't really a problem, due to the LogIn form not being used for one. But consider the Custom Authentication and Forms Authenication. The LogIn form is tightly coupled to FormsAuthentication, more specifically to System.Web.Security. (i.e. Membership.ValidateUser, FormsAuthentication.SetAuthCookie, etc...).
I'd like to Inject into my AccountController the authentication to use, rather than having FormsAuthentication and Membership be used.
Does this make more sense in so far a what my problem is?
They're actually not so tightly coupled. The templates are just trying to get you up and running quickly.
ASP.NET membership supports both Forms and Domain auth.
In a site configured for Forms auth, e.g., you'll see a line in Web.config like:
<authentication mode="Forms">
You can change that to:
<authentication mode="Windows">
That's not the only difference (with Windows auth, e.g., you don't need a login page), but it's the most significant. You write your code based on the ASP.NET Membership API and only target Forms authentication in particular when you have to.
I agree with Craig's answer. The only thing I have to add is that I consider just about anything you can change in the web.config to be loosely coupled. The reason is that you can apply web.config transforms when you create a deployment package for your MVC app.
We use Unity for DI/IoC, and you can also specify your injection dependencies in web.config using Unity. You would just write your Web.Auth1.config to configure your app for one kind of authentication, and Web.Auth2.config to configure it for another kind of authentication. Then when you deploy, you just pick the target and VS builds the correct configuration for you.
If your source code needs to know which type of auth is used in the deployment, you could tell it with a web.config appSetting, which can also be changed with a web.config transform during deployment.