|
lasses and methods that make it easy for you to create them programmatically, in particular the FormsAuthentication class. It’s HashPasswordForStoringInConfigFile method can do the hashing. At a lower level, you can use the System.Security.Cryptography classes, as well. We''''ll be looking at the former method later in this article.
The flexibility of the authentication provider for Forms Authentication continues as we can select SQLServer as our data source though the developer needs then to write bespoke code for validating user credentials against the database. Typically you will then have a registration page to allow users to register their login details which will then be stored in SQLServer for use when the user then returns to a protected resource and is redirected to the login page by the forms authentication, assuming the corresponding cookie is not still in existence.
This raises a further feature - we would want to give all users access to the registration page so that they may register but other resources should be protected. Additionally, there may be a third level of security, for example an admin page to list all users registered with the system. In such a situation we can have multiple system.web sections in our web.config file to support the different levels of authorization, as follows:
<configuration>
<system.web>
<authentication mode="Forms">
<forms name=".AUTHCOOKIE" loginURL="login.aspx" protection="All" />
</authentication>
<machineKey validationKey="Autogenerate" decryption key="Autogenerate" validation"SHA1" />
<authorization>
<deny users="?" />
<authorization>
</system.web>
<location path="register.aspx">
<system.web>
<authorization>
<allow users="*,?" />
</authorization>
</system.web>
</location>
<location path="admin.aspx">
<system.web>
<authorization>
<allow users="admin " />
<deny users="*" />
</authorization>
</system.web>
</location>
</configuration> Thus only the admin user can access admin.aspx, whilst all users can access register.aspx so if they don''''t have an account already they can register for one. Any other resource request will cause redirection to login.aspx, if a valid authentication cookie by the name of .AUTHCOOKIE isn''''t detected within the request. On the login page you would provide a link to register.aspx for users who require the facility.
Alternatively you can have multiple web.config files, with that for a sub-directory overriding that for the application a whole, an approach that we shall implement later for completeness.
Finally, you may also perform forms authentication in ASP.Net against a Web Service, which we won’t consider any further as this could form an article in itself, and against Microsoft Passport. Passport uses standard web technologies such as SSL, cookies and Javascript and uses strong symmetric key encryption using Triple DES (3DES) to deliver a single sign in service where a user can register once and then has access to any passport enabled site.
Consideration of suitabilityForms based authentication is a flexible mechanism supporting a variety of techniques of various levels of security. Some of the available techniques may be secure enough for implementation if extended appropriately. Some of the techniques are more suited to our problem domain than others, as we’ll discuss shortly.
In terms of specific authorities:
Passport is most appropriately utilized where your site will be used in conjunction with other Passport enabled sites and where you do not wish to maintain your own user credentials data source. This is not the case in our chosen problem domain where Passport would both be overkill and inappropriate.
SQLServer would be the correct solution for the most common web site scenario where you have many users visiting a site where the majority of content is protected. Then an automated registration facility is the obvious solution with a configuration as per the web.config file just introduced. In our chosen problem domain we have stated that we potentially have only a handful of users accounts accessing a small portion of the application functionality and hence SQLServer is not necessarily the best solution, though is perfectly viable.
Use of the credentials section of the forms element of web.config or a simple text/ XML file would seem most suitable for this problem domain. The extra security and simplicity of implementation offered by the former makes this the method of choice.
Authorization via ASP.NetAs discussed earlier this is the second stage of gaining access to a site: determining whether an authenticated user should be permitted access to a requested resource.
File authorization utilizes windows security services access control lists (ACLs) – using the authorized identity to do so. Further, ASP.Net allows further refinement based on the URL requested, as you may have recognized in the examples already introduced, as well as the HTTP request method attempted via the verb attribute, valid values of which are: GET, POST, HEAD or DEBUG. I can''''t think of many occasions in which you''''d want to use this feature but you may have other ideas! You may also refer to windows roles as well as named users.
A few examples to clarify:
<authorization>
<allow users=”Chris” />
<deny users=”Chris” />
<deny users=”*” />
</authorization> You might logically think this would deny all users access. In fact Chris still has access, as when ASP.Net finds a conflict such as this it will use the earlier declaration.
<authorization>
<allow roles=”Administrators” />
<deny users=”*” />
</authorization>
<authorization>
<allow verbs=”GET, POST” />
</authorization>
ImpersonationImpersonation is the concept whereby an application executes under the context of the identity of the client that is accessing the application. This is achieved by using the access token provided by IIS. You may well know that by default the ASPNET account is used to access ASP.Net resources via the Aspnet_wp.exe process. This, by necessity, has a little more power than the standard guest account for Internet access, IUSR, but not much more. Sometimes you may wish to use a more powerful account to access system resources that your application needs. This may be achieved via impersonation as follows:
<system.web>
<identity impersonate=”true” />
</system.web> or you may specify a particular account:
<system.web>
<identity impersonate=”false” userName=”domain\sullyc” password=”password” />
</system.web> Of course you will need to provide the involved accounts with the necessary access rights to achieve the goals of the application. Note also that if you don’t remove IUSR from the ACLs then this is the account that will be used – this is unlikely to meet your needs as this is a less powerful account than ASPNET.
ASP.Net will only impersonate during the request handler - tasks such as executing the compiler and reading configuration data occur as the default process account. This is configurable via the <processModel> section of your system configuration file (machine.config). Care should be taken however not to use an inappropriate (too powerful) account which exposes your system to the threat of attacks.
The situation is further complicated by extra features available in IIS6 … but we’ll leave those for another article perhaps as the situation is complex enough!
Let’s move onto developing a login solution for our chosen problem domain.
Our Chosen Authentication Method – how secure is it?We''''ve chosen forms based authentication utilizing the web.config file as our authority. How secure is the mechanism involved? Let''''s consider this by examining the process in a little more detail. As a reminder, our application scenario is one of a web site where we''''ve put content which we want to enable restricted access to in a sub-directory named secure. We have configured our web.config files to restrict access to the secure sub-directory, as described above. We deny access to the anonymous users (i.e. unauthenticated users) to the secure sub-directory:
<authorization>
<deny users="?" />
</authorization> If someone requests a file in the secure sub-directory then ASP.Net URL authentication kicks in - ASP.Net checks to see if a valid authentication cookie is attached to the request. If the cookie exists, ASP.Net decrypts it, validates it to ensure it hasn''''t been tampered with, and extracts identity information that it assigns to the current request. Encryption and validation can be turned off but are enabled by default. If the cook上一页 [1] [2] [3] [4] 下一页
[网络安全]赶尽杀绝—查杀AOL Trojan木马 [Sql Server]不用SqlTransaction执行数据库事务处理
[Web开发]用SqlCommandBuilder 实现批量更新 [Web开发]NET下随机数(Random)的产生（应用）
[Web开发]出现SqlTransaction 已完成;它再也无法使用的错误… [Web开发]出现SqlTransaction 已完成;它再也无法使用的错误…
[平面设计]Flash随机random函数详解 [平面设计]网页动画制作大师 Animation Shop
[平面设计]制作动态GIF图像的好帮手─Coffee GIf Animator [平面设计]可以有效降低网页动画大小的网页动画制作软件—An…
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
