I have this in mind.
I just want to check if there is something like what I have in mind already done, or I should I want to work on:
MVC3 application using asp.net membership, that has single sign on (so it is a claims aware
app that will log on a STS).
I have seen http://identityserver.codeplex.com/ but not analized it in detail:
Is it a good solution to implement?
My question is:
Is there anything like that done?
Is it a common way of doing SSO? (using also membership?)
Thanks!..
IdentityServer is an STS not an application.
If you have a claims-aware application, it "emulates" the membership provider. You can configure ADFS to provide the roles and then use the standard .NET constructs
IsInRole() or
location>
...
allow role = ...>
in the web.config.
Related
I have an ASP.NET 5 (RC1) application for which I am trying to set up authentication and authorization. However I am confused and overwhelmed by all the varying authentication and authorization information online in as it pertains to this platform. Much of it seems either hopelessly out of date or simply doesn't seem to apply in this particular usage scenario. Right now, I'm not even sure what the right 'terminology' to use for the question I am trying to ask, but I digress.
What I am trying to accomplish is a system whereby users are authenticated/authorized via Azure AD (B2C?), with additional user profile information stored in a database. However, the user context in the controllers is accessed in a consistent way using what I presume would be a custom ClaimsPrincipal/ClaimsIdentity? I would imagine this should be as simple as adding an 'authorize' attribute or something similar and accessing the ClaimsPrinciple.Current.Claims.
I have used ASP.NET Identity in the past, but many of the examples I have found aren't using that. Most are simply using the UseOpenIdConnectAuthentication middle-ware. I see that ASP.NET Identity is still available but I'm not sure it applies in this scenario. I also found a couple posts on here suggesting using a custom ClaimsIdentity to accomplish this, but I am having trouble finding useful up to date examples. BTW, I realize that much of this "profile" information can be stored as custom attributes in azure ad but the way some of the information is used within the application prohibits all of it from being in azure (i.e. EF linq joins and such).
Please, tell me if I am even close on some of this. I know this is a fairly new platform and the information is sparse, but certainly I'm not the only one asking these questions.
Just calling out an excellent article Identity management for multitenant applications in Microsoft Azure.
A lot of your questions are answered there.
e.g. you can augment the claim in the OWIN middleware AuthenticationValidated event.
ASP.NET Identity is claims-based in that the attributes are delivered as claims but authentication is on the DB, not via external IDP like Azure AD.
B2C is a special case in Azure AD - used for many (millions!) external users who can self-register and self-manage e.g. SSPR.
B2C uses a separate tenant to the normal Azure AD one and the users have no access to things like O365 or any SaaS applications.
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.
I'd like to support multiple authentication mechanisms such as oAuth and ADFS in my MVC site. Is this possible, and how would I go about using one or the other?
My understanding is that ADFS/WIF will hook into the entire site preventing alternates such as oAuth
FedUtil only allows an application to point to one instance of ADFS. If you use it again to point to another instance, it simply overwrites the old ADFS info. in the web.config.
The trick is to federate ADFS with another STS which does support the OAuth protocol.
StarterSTS is an example of an STS which supports OpenId. This was developed by Dominick Baier. He has just announced via his blog that he is developing a MVC version.
Matias Woloski has blogged about a protocol bridge here. It supports not only OpenID but also OAuth.
#nzpcmad suggestion of adding an STS to do protocol translation is correct. Another alternative is to use ACS (AppFabric Access Control Service).
You can alternatively add the trusts relationship on the web.config manually (or run Fedutil on a separate project and merge the changes). In this case the trust would be to an STS that knows how to deal with OAuth and SAML/WS-Federation (like the STSs mentioned by #nzpcmad). Out of the box, WIF only understands SAML tokens and WS-Federation/WS-Trust.
StarterSTS does not support OAuth but the follow-on project by the same guy does. Check out http://identityserver.codeplex.com/ for more details.
In addition to supporting OAuth it is new code using the ASP.NET MVC framework and WCF for its underpinnings.
This is only at CTP 1 status and is not yet considered a full release yet so review carefully.
Does anyone know is there a way to implement Windows Live ID authentication into your ASP.NET MVC site. I am moving a project from Web Forms to a MVC solution and do not want to rebuild the database so ASP.NET Membership mentioned in windows-live-id-in-asp-net-mvc is not a valid solution.
And just to avoide this question the customer not want to use Open ID.
I don't fully understand your question, but here's an example of a MVC.NET app which uses LiveID but doesn't use an ASP.NET Membership provider:
http://blog.smarx.com/posts/actually-i-m-a-cia-agent