I am trying to implement custom authentication using the new ASP.NET Identity in an MVC 5 project.
I have a single username and password that I want to use to restrict which pages of the website the user can see via [Authorize] tags on controllers and views. (Easy)
I am migrating from a FormsAuthentication model whereby this was as simple as putting the credentials in the web.config.
Because I only have a single username and password I don't want to use a database as the UserStore, instead I want ASP.NET Identity to retrieve the username and password from a custom configurationsection in the web.config (don't worry about that part).
After much search, I can't find a code sample that doesn't rely on a database for ASP.NET Identity authentication.
So i'm looking for a code sample that at the point of authentication, the user can put in custom code to check the username & password against the credentials in the custom ConfigurationSection of the web.config.
Can someone please point me in the right direction thanks.
Update : I've tried looking at this code sample but it doesn't even compile out of the box.. poor.
http://code.msdn.microsoft.com/Simple-Aspnet-Identiy-Core-7475a961
Update : The reason that I don't want to use FormsAuthentication is that I am writing a NuGet package that will be installed into a web application. One of the things the NuGet package will do is create a custom ConfigurationSection in the web.config that includes (among other things) a single username and password. I thought this would be safer as it wouldn't alter any existing FormsAuthentication settings currently in the target web application.
Update : I think I have got it working. Will post findings soon.
-- Lee
You don't have to migrate to Identity framework, FormsAuthentication still works. And Andrew is correct, using Identity framework makes little sense here, since it is all about managing users.
However, if you insist on using it, you can implement your own UserManager and IUserStore. Some guidance can be found in Scott K. Allen blog post. See the links on the bottom - samples of implementations - you can take some of these and convert to your needs.
I would imagine your IUserStore will be simple, because there is only one user and most of the methods don't have to be implemented. And for the ones required (I think you'll need FindUserById and related) you'll need to reach to web.config via ConfigurationManager
Related
I have been reading a lot about how to implement a full authentication and authorization system in Asp.Net Web Api 2 which includes registering, sending email confirmations, issuing both access tokens and refresh tokens, etc. I have successfully done all of that after all, however, it looks such an un-necessary over head to have to do it for every single project.
I am still not sure, but I believe the "Thinktecture IdentityServer" is a package that has been put together to provide all of this, am I right?
If yes, can anyone tell me (in a very straight forward way) how can I create a new Web Api project and easily get all the above mentioned features using this package?
Thinktecture identity server v3 is a collection of highly configurable modules, so there is a fair amount of code to write to set it up how you want it. The Thinktecture wiki has a good 'hello world' example that might be enough to get you going:
Hello world
After that, download the samples, find the one that most closely matches your situation, and build upon that. In particular, you'll want to set up a database to save your registered users to. The related 'MembershipReboot' project is generally the one you use to do data access, along with the 'MembershipReboot.Ef' addon that will autocreate your database using EntityFramework.
MembershipReboot is where you set up which email events you want to use.
Email config in membership reboot
Here's To USE the identityServer3 that you set up separately:
(IdentityServer3 has some out of the box server-setup examples that may be good enough for you, or might only need a slight configuration)
Nuget the Microsoft OpenID Connect (I think its called: Microsoft.Owin.Security.OpenIdConnect)
Point the OpenID Connect middleware (also in Startup.cs) to the IdentityServer.
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
Authority = "https://myIdsrv3Path/identity",
ClientId = "myapi",
RedirectUri = "https://myIdsrv3Path/", // or
ResponseType = "id_token",
SignInAsAuthenticationType = "Cookies"
});
In the IdentityServer3 set the accepted clients to include "myapi", with the claims you need.
There is more to explain about authorization, but this answers your basic question for securing an api.
See the IdentityServer3 documentation:
https://identityserver.github.io/Documentation/docsv2/overview/mvcGettingStarted.html
Scroll down to the section called: Adding and configuring the OpenID Connect authentication middleware.
I'm struggling with a custom authentication mechanism for Symfony2.
What I want to do:
I need a modified behaviour of the regular UsernamePasswordForm based authentication. The only modification required is, that the credentials aren't checked against the database, but some custom unix auth deamon. The users themselves are still located in the database.
What I did:
I played around will a full fledged custom authentication provider based on this Symfony cookbook entry and will most parts just extending the different UsernamePassword classes, but it didn't work out yet. I had especially some problems setting up the AuthenticationListener in the service configuration as the UsernamePasswordFormAuthenticationListener has a lot of required parameters. Currently I'm not sure if it will work out at the end, cause I've got some issues with our database setup.
What I need:
Is there a simpler way to modified the default login form without the complete requirement of a full AuthenticationProvider? Imho it's a quite common issue to have some custom modifications in the default behaviour.
Would be happy about any ideas or hints.
I have not tried this myself but you should be able to insert your own AuthenticationProvider by setting a paramter:
security.authentication.provider.dao.class:
..Security\Core\Authentication\Provider\MyDaoAuthenticationProvider
Your provider would extend the Dao and overide checkAuthentication.
Again, I have not actually done this and the security system is very touchy so it may or may not work.
Answering my own question: I finally managed to solve my issue thanks to this blog post showing a solution. The basic idea is to extend the default form login authentication and "steal" its listener. This way you can reuse most of the existing code. The critical parts are the creation and configuration of an AuthenticationProvider and a SecurityFactory. And don't miss to use your own provider key instead of form_login in the security.yml.
In the blog post the author creates his own UserProvider, but it's working with just the default database one, too.
What is the preferred way of integrating a custom membership provider with Orchard?
I have seen a couple of posts around implementing a new IMembershipService and IUserService (from Orchard.Users) and then there other modules such as OpenAuthentication which seem to do a lot more than that (but still uses the UserPart??).
We already have an ASP.NET Membership provider written, can this be integrated as is?
Custom implementation of IMembershipService is a way to go if you don't want to use the default Orchard.Users module at all. Useful when you still want to do forms authentication, but just store the auth data somewhere else, not in UserPart.
If you would like to create a totally custom authentication scheme, that overrides the form-based default one (username + password), override IAuthenticationService.
So, generally speaking:
IMembershipProvider is about authentication data management (create/retrieve users)
IAuthenticationProvider is about performing the authentication (sign in/out/get current user etc.)
Depending on your needs you can override either one or both.
The common auth modules, like the OpenAuth one, add additional authentication options to the existing default one without actually replacing it, IIRC.
I'm building my first backbone app, and though I'm doing my authentication server side, there are features that non-authenticated users are unable to use, but because they are in my asset path, and part of my backbone files, everything gets loaded.
Is there a way to load only the resources that a user is actually able to use?
I'm using Rails with cancan to manage this server-side.
You need to split the assets out in to separate groups: a group that can be used by anyone, and a group that can be used by authenticated users. Only send the code that the user is allowed to use, basically.
I wrote a post about doing this with asp.net mvc recently. the same idea applies to rails, though the use of the asset pipeline makes the implementation a bit different:
http://lostechies.com/derickbailey/2012/01/26/modularity-and-security-in-composite-javascript-apps/
The best way is to create a Base view with a property named requireLogin: true/false.
All other views should inherit this view and the views which need authentication you should set requireLogin:true, for all others this property should be false.
After this you should handle the authentication base of this property.
I am building a Sharepoint web part that will be used by all users, but can only be modified by admins. The web part connects to a web service which needs credentials. I hard coded credentials in the web part's code.
query.Credentials = new System.Net.NetworkCredential("username", "password", "domain");
query is an instance of the web service class
This may not be a good approach. In regard with security, the source code of the web apart is available to people who are not allowed to see the credentials.
In normal ASP.net applications, credentials can be written into web.config and encrypted. A web part doesn't have a .config file associated. There is a application-level .config file for the whole sharepoint site, but I don't want to modify it for a single webpart. I wonder if there is a webpart-specific way to solve the credential problem? Say we provide a WebBrowsable property of that web part so that privileged users can modify credentials. If this is desirable, how should I make the property displayed in a password ("***") rather than in plain text?
Thanks.
Create custom toolpart, check for condition like SPWeb.UserIsWebAdmin, if so, render fields needed for credentials (input textbox, masked textbox etc).
Read the user name and password out of an encrypted section of the configuration file. See https://web.archive.org/web/1/http://blogs.techrepublic%2ecom%2ecom/programming-and-development/?p=448 for more info on programmatic uses.
In addition to the above, you can store the credentials (securely, of course) on the server, be it config file symlinked in, a file in a known location (e.g., common directory) or even (not recommended) in the environment.
A bonus of this method is it allows dev/test/whatever to have different credentials and not interfere with production while developing/testing/etc.
If you want the web part to be independent of other parts of the system, a property is the simplest option. The main downside to that approach is that you can't set permissions for individual properties, so users will see it. You could have the value be a hash (calculated elsewhere by the admin before adding the web part) but I don't think I'd call that a good solution.
If you want to provide ui to admins only, you should create a custom settings page (CustomAction + layouts page) which saves the credentials in a site property, possibly encrypted so that they can only be read by your custom code in the web part and settings page.