Security

Modified on Wednesday, 01 June 2011 09:15 AM by Administrator — Categorized as: Uncategorized


Authentication

There are currently three (3) approved authentication mechanisms for use by applications; however their use is further limited by where the application will be deployed.

Authentication MethodIntranetInternet
RACFYesYes
Active Directory (AD)YesNo
Internet Subscriber Account (ISA)NoYes

To facilitate the use of these approved authentication methods the FEL provides membership providers for use with ASP.NET 2.0 web applications. The available providers are:
Regardless of the method you choose applications at FDOT are typically configured to use forms authentication. To do this, configure the authentication node of your web.config file as follows: 

<authentication mode="Forms"> 
<forms loginUrl="login.aspx"/>
</authentication>

The sample sets the authentication mode to forms and defines login.aspx as the login page for the application. This is the page that users will be directed to if they attempt to access a resource they do not have access to because they are not authenticated.

Once the membership provider is configured in the web.config file all that remains is to add the common login control to your login form. All the work required to process the user’s credentials and determine if they can access a resource will occur behind the scenes.

Active Directory

Active Directory (AD) is used to secure non mainframe resources on the FDOT network; all users that have access to FDOT’s internal network will have an AD user id. FDOT’s AD implementation is not however exposed to the internet so it is not available for use if the application will be deployed to the Internet.

There are a couple of options available for using AD based authentication, you can either use forms based authentication as you would with the RACF and ISA providers or you can use Windows authentication.

We will focus on forms based authentication with the ADMembershipProvider for this document. To use the provider you need to setup forms authentication and then configure the provider in the web.config for the application as follows:


<membership defaultProvider="MembershipProvider"> 
<providers>
<add name="MembershipProvider" type="FDOT.Enterprise.Architecture.Web.Security.ADMembershipProvider"/> 
</providers>
</membership>

Internet Subscriber Account

The Internet Subscriber Account (ISA) system was created to address the need to allow public users to interact with applications on the internet and store/retrieve their settings without needing to have a RACF account created. Applications can create ISA accounts for new users as needed. NOTE: Applications intending to use this authentication method will need prior approval from the security office; for further information please contact the Computer Security Adminstrator. This is only available for applications on the internet and only for users that are not FDOT employees.

To use the provider you need to setup forms authentication and then configure the provider in the web.config for the application as follows: 

<membership defaultProvider="MembershipProvider">
<providers>
<add name="MembershipProvider" type=" FDOT.Enterprise.Architecture.Security.InternetSubscriberAccount.ISAMembershipProvider"/>
</providers>
</membership>

Authorization

There is currently no defined standard method of role management for applications. Available options include using RACF profiles, AD groups or implementing application specific role tables. The FEL provides 2 role providers:
Authorization settings are configured in the web.config file by setting up the authorization node as follows: 

<authorization> 
<deny users="?"/>
</authorization>

This will prevent unauthenticated users from accessing any resources within the applications. This can be made to be far more granular allowing restrictions based on individual resources or folders and restricting them by role, specific user or access method. More information on configuring authorization is available at http://msdn2.microsoft.com/en-us/library/wce3kxhd.aspx

NOTE: To use RACF groups for authorization the following steps have to first be completed on the mainframe:
  1. Users should be added to designated RACF Groups
  2. Each RACF group should be associated with a CICS general resource profile for the CICS security transaction BS75
  3. Assign LU 6.2 connect "userid" CICCTP2 (production) and CICCTT2 (system test)

RACFRoleProvider

The RACF role provider allows an application to use RACF profiles to be used as application roles. This provider has to be used in conjunction with the RACF membership provider. To enable the role provider add the following section to your web.config file. 

<roleManager defaultProvider="RACFRoleProvider" enabled="true"> 
<providers> 
<add name="RACFRoleProvider" type="FDOT.Enterprise.Architecture.Web.Security.RACFRoleProvider"/> 
</providers>
</roleManager>

In addition you will also need to have the following application setting in your web.config file. 

<configuration>
<appSettings> 
... 
<add key="validRACFRoles" value="RACFRole1, RACFRole2"/> 
... 
<appSettings>
<configuration>
This defines the list of valid RACF profiles for your application and is the list users will be checked against.

ISARoleProvider

The ISA role provider allows an application to use ISA and RACF roles. This provider has to be used in conjunction with the ISA membership provider. To enable this provider for an application include the following in the web.config file. 

<roleManager defaultProvider="ISARoleProvider" enabled="true"> 
<providers> 
<add name="ISARoleProvider" type="FDOT.Enterprise.Architecture.Security .InternetSubscriberAccount.ISARoleProvider"/>
</providers>
</roleManager>

NOTE: the ISA role provider uses the RACF role provider for users that login using their RACF user id and therefore requires the validRACFRoles application setting as described for the RACF role provider. 

<configuration> 
<appSettings> 
... 
<add key="validRACFRoles" value="Group1,Group2"/> 
... 
<appSettings> 
<configuration>

Other Authorization Methods

Many applications implement their own role management systems using a private set of tables. The typical pattern used is to check the user’s authority level when they log in to the application by subscribing to the LoggedIn event of the login control. This information can then be persisted in the user’s session and used to determine what the user has access to.

See Also