Am I right in presuming that the ASP.Net Membership Manager fails to provide the same facilities as the Acitve Directory in as much as:-
preventing old password re-use (say, not in last five passwords)
preventing change of password within a certain number of days (to stop recycling to facilitate use of same password)
Cheers
No the default ASP.NET Membership Provider doesn't do either of those things as default.
You would have to create your own code to manage this yourself.
Related
I am fairly new to coding in the .Net environment. I am having trouble finding "real-world" examples on authentication/authorization using Identity. Most examples I come across are primarily textbook examples that use the ASP .Net registration template.
I am trying to find guidance on where to look (yes, I Googled and I get very unrealistic/unusable use cases or "classroom" examples) or how to do this.
I work for a small school and I am trying to build an application (possibly Blazor - just experimenting with various technologies now) that allows both students and employees to login into a portal and view their relevant data. I have an Employee table and a Student table based on POCO classes. When I add identity to the project it creates Users and Roles tables as well.
I would like to have the "Users" table based on the Student and Employee tables - not have a separate users table. I do not want to have a "registration" option either. I would like the option for an Admin (which would fall under an "Employee") to be able to add users, but not use a registration page.
How would I implement Identity and Roles without using all the extras added? I am using .Net 5.0.
Thank you for your time and pelase forgive the English - it's new to me as well.
I understand what you're trying to do. It IS possible to Create a Custom AuthenticationStateProvider
But unless you have a VERY robust database already, I wouldn't do it. Getting the default system set up and migrating users will take at most an hour. Setting up your own custom authorization system is likely to take you MUCH MUCH longer.
Having different users in different tables is not a good design plan. They all have names, phone numbers, e-mails and so on-- put them on one table.
Hi Derrick and welcome to the community! #Bennyboy1973 is correct, in that both your Students and Employees are all "Users", so they should all be stored in the same table. To add to that response a bit, probably the simplest way for you to manage them is by using Roles, so the Students could be in one role and the Employees could be in another. By having a role attached to each, you can then use the roles as a filter in your queries and you could also restrict the access and actions each type will have based on the role they are in.
Regarding having administrators add the users to the database without public access, this can be done as well. Once you get the default identity system up and running, you can scaffold out the whole system so it can be modified, and probably the easiest way to achieve what you are after is to then modify the default registration (signup) page so that it requires the user to be authenticated to reach it, and then implement a confirmation email to activate each new account.
There are a few things with this approach that you need to be aware of as well.
Since the admin will be setting up all the other user accounts, you should modify the email confirmation chain to require a password reset at some point. The administrators can have access to the user's information as needed but shouldn't have the user's passwords.
Identity Server will store passwords in an encrypted format, and you'll need an initial user in your database. What this means is that you will have to "seed" an initial admin user into the database that you can use to sign in and get started with everything else. You'll have to research how to do this, as it isn't as simple as just accessing the database directly and adding the user and roles because of the encryption. The program you build should be designed to do this for you on either the first run or if you are connecting to a new database, using a username and password that you know. It will then store the user properly that you can use to sign in as Admin, then change the admin password. This makes the whole thing more secure.
This all sounds like a headache, but it's worth it to work through and know how it all fits together. The, as mentioned in other answers, you can migrate existing data into the database.
I'm changing a completed website project structure from web form to MVC. Having more than 100 users and the current login system is with browser cookies.
My problem is with the user passwords, which are saved using one way hashing system in SQL store procedure:
HashBytes('SHA1', CONVERT(nvarchar(4000),#password))
Is there any possible way to change the old system and use ASP Identity Users in the project?
Identity used salted hashed passwords rather then just hashed passwords. You could probably do a custom usermanager to use your existing logic but I wouldn’t recommend it. You are probably better off requiring that users on login reset their passwords with a notice about improving security.
I have moved along nicely migrating to simplemembership. The only thing that is hanging me up now is how do I configure password settings such as whether it's hashed, clear, or encrypted, etc. I don't believe it will be in the web.config any longer.
Simplemembership is Designed around a specific view of users, roles and profiles
The existing providers are focused on traditional membership - a user has a username and a password, some specific roles on the site (e.g. administrator, premium user), and may have some additional "nice to have" optional information that can be accessed via an API in your application.
This doesn't fit well with some modern usage patterns:
In OAuth and OpenID, the user doesn't have a password
Often these kinds of scenarios map better to user claims or rights instead of monolithic user roles
For many sites, profile or other non-traditional information is very important and needs to come from somewhere other than an API call that maps to a database blob
What would work a lot better here is a system in which you were able to define your users, rights, and other attributes however you wanted and the membership system worked with your model - not the other way around.
You can't retrieve passwords with SimpleMembership, but you can let the user reset them. There is no workaround.
You must use some other membership provider, such as the standard SqlMembershipProvider, which may also not allow you to retrieve a password in clear text.
The days of retrieving a password in clear text is over, as this is a major security risk if it ends up in the wrong hands.
Hope this clears up some of your thinking about what you wish to achieve.
Some reading:
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
Migrating from ASP.NET Membership to SimpleMembership in MVC4 RTM
http://brockallen.com/2012/09/02/think-twice-about-using-membershipprovider-and-simplemembership/
SimpleMembership does not allow you to choose the password format.
I am developing a WCF service which can be consumed by mobile applications to authenticate users against the corporate extranet ActiveDirectory. I am using a customized version of this implementation from Microsoft. I need to implement the account lock out logic so that after n retries the account in the ActiveDirectory should get locked-out.
I tried with state-full WCF service to keep track of the failed log-ins. But the client can start over the next session and continue with the attack.
I know that the ActiveDirectory policy can be set to enforce this, but just querying the AD -like the Microsoft solution does to authenticate the user - does not lock out the user.
So, I am looking forward for a solution which will work like when log-in to Windows with incorrect password for n times the account will get locked-out as per the policy set in the AD.
I have not seen your code. So I'm guessing you have similar solution that is implemented in this example, have a look at this link
In above example, please have look at line
DirectoryEntry entry = new DirectoryEntry(_path, domainAndUsername, pwd);
this entry object would be used for authentication when you make a search call on active directory.
If you are using user/password that you want to authenticate then you need not to worry about locking it by your code. Active directory policy would be enough.
But after reading your comment I guess you have one specific user that you use to search mobile application users to check if they exist in your active directory or not. If this is the case effectively you are never authenticating against mobile users so those users never going to be blocked automatically.
I would be interested to know your answer.
There are basically two ways of doing this:
You continue the directory search method you are using, but track the number of logins for each user in a custom database, and check this database before doing the directory search.
Use the Windows login instead, and rely on AD to lockout the user. For a description of how to do this check: Active Directory (LDAP) - Check account locked out / Password expired
Edit
After seeing marc_s's comment, I am unsure if doing the directory search will lockout or not. It would actually be a serious security hole if you could try an infinate number of times. But you would need an account that is allowed to query AD before you could use it.
The code you linked to had this line
object obj = entry.NativeObject
Which was to force authentication. Have you included this line?
How to set password (the best if it was in database, so Entity with one record) on some pages (create/edit/delete view and controllers)? It can be redirect to entrance page with form with password field.
I would also recommended you to go with 'spring security core' plugin.
By using spring security core you will be able to :
(1) secure all of your project's possible URLs
(2) provide access to required pages to particular role
(3) assign one or more then one role to particular user
(4) manage individual users with basic information as well as storing password into encrypted form etc.
(5) Its in-built reach set of tag library will help you alot to reduce the logical code.
Apart from the above, the major advantage of using spring security core would be its simplicity and extensibility. As its advance features like :
LDAP
ACL
OpenID
CAS etc
are available with different plugins.
Also there is one more plugin called 'spring security ui' is available, which will provide you all the UI pages (with gsps,controllers) just in a minute.
I have used this plugin in my project before one year, and I would strongly recommended everyone to use it...
You can have a look into its simple User guide which is available here.
Use one of the security plugins, and make the actions that you want to protect only available to users with a particular role. If an unauthenticated user tries to access one of these actions, they will be prompted to login and invocation of the action will only be allowed thereafter if they have been assigned the relevant role.
The spring security plugin is a reasonable choice as it provides the functionality you need and probably the most popular of the Grails security plugins.