user-pull-host-based mode
- the user needs to download her roles from the role server and store them in her machine (which has her host-based authentication information, such as IP numbers)
- later, when Alice wants to access the Web server, which requires proper authentication information and roles, her machine presents that information to the Web server
- after client authentication and role verification, the Web server uses the roles for RBAC
- since this mode is host-based, it cannot support high user mobility
- the user can download her roles to her current machine from the role server
- then, she presents those roles to the Web server along with her user-based authentication information, such as her passwords
- after user authentication and role verification, the Web server uses the roles for RBAC
- in this mode, the user can use any machine that supports HTTP, as long as she has the right user-based authentication information (e.g., passwords)
Server-pull architecture
server-pull-host-based mode
- she presents host-based authentication information (e.g., IP numbers) to the Web server
- the role-obtaining mechanism is transparent to the user, while limiting user portability
- after user authentication, the Web server downloads the user’s roles from the role server and uses them for RBAC
- Alice presents user-based authentication information (e.g., passwords) to the Web server
- this supports high user portability, while it requires the user’s cooperation (e.g., typing in passwords)
- after user authentication, the Web server downloads the user’s roles from the role server and uses them for RBAC
Secure cookies
Authentication services verify the owner of the cookies.
Integrity services protect cookies against the threat that their contents might be changed by unauthorized modification.
Finally, confidentiality services protect cookies against having their values revealed to an unauthorized entity.
Common fields for cookies
- Cookie_Name and Cookie_Value contain information a Web site would want to keep. For example, in the figure, the values of Name_Cookie and Role_Cookie are “Alice” and “Manager,” respectively.
- Date is the cookie’s valid lifetime.
- Domain is a host or domain name where the cookie is valid.
- Flag specifies whether or not all machines within a given domain can access the cookie’s information.
- Path restricts cookie usage within a site (only pages in the path can read the cookie).
- If the Secure flag is on, the cookie will be transmitted over secure communications channels only, such as SSL.
According to the current HTTP state management mechanism, whenever a browser requests a URL to a Web server, it sends only the relevant Cookie_Name and Cookie_Value fields (selected by the Domain and Flag fields) to the server.
The cookie issuer is not important for validation; any Web server can issue cookies for other Web servers.
Security threats to typical cookies
- network security threats - cookies transmitted in clear text on the network are susceptible to snooping (for subsequent replay) and to modification
- end-system threats - Once the cookie is in the browser’s end system, it resides on the hard disk or memory in clear text. It is trivial to alter such cookies, and they are easily copied from one computer to another, with or without the connivance of the user on whose machine the cookies were originally stored.
- cookie-harvesting threat - an attacker collects cookies by impersonating a site that accepts cookies from the users (who believe that they are communicating with a legitimate Web server) and later using those harvested cookies for all other sites that accept them
- Name_Cookie contains the user’s name (e.g., Alice)
- Role_Cookie holds the user’s role information (e.g., Manager)
- Life_Cookie is used to hold the lifetime of the secure-cookie set in its Cookie_Value field and enables the Web server to check the integrity of the lifetime of the secure-cookie set
- IP_Cookie holds the IP number of the user’s machine
- Pswd_Cookie holds the user’s encrypted passwords
- Seal_Cookie has the digital signature or MAC (Message Authentication Code of the cookie-issuing server on the secure cookie set and protects cookies against the threat that their contents might be changed by unauthorized modification
RBAC implementation
Using secure cookies
- She first connects to the role server in the beginning of the session.
- After the role server authenticates Alice, it finds Alice’s explicitly assigned roles in the URA database and creates a set of secure cookies. Those secure cookies are then sent to and stored securely in Alice’s hard drive, so that Alice does not need to go back to the role server to get her assigned roles until the cookies expire.
- When Alice requests access to a Web server—which has PRA information—by typing the server URL in her browser, the browser sends the corresponding set of secure cookies to the Web server.
- The Web server authenticates the owner of the cookies by using the authentication cookies, such as IP_Cookie and Pswd_Cookie, comparing the values in the cookies with the values from the user.
- Finally, the Web server checks the integrity of the cookies by verifying the role server’s digital signature in the Seal_Cookie using the role server’s public key.
- If all the cookies are valid and successfully verified, the Web server trusts the role information in the Role_Cookie and uses it for RBAC with role hierarchy and permission-role assignment information in the Web server.
Creating secure cookies
- When a user connects to the role server, she is prompted by the HTML form to type in her user ID and passwords for the domain. The “set-cookie.cgi” program authenticates the user by comparing the user ID and passwords with the ones in the authentication database. It then assigns the user to roles by matching the user ID and the corresponding roles from the URA (user-role assignment) database.
- Subsequently, a subroutine for encryption is called to another CGI program (encrypt.cgi), which uses PGP to encrypt the passwords by the cookie-verifying Web server’s public key. These encrypted passwords will be stored in the Pswd_Cookie by the “set-cookie.cgi” program.
- The “setcookie.cgi” program then creates IP_Cookie, Pswd_Cookie, Name_Cookie, Life_Cookie, and Role_Cookie.
- To support the cookies’ integrity service, the “set-cookie.cgi” program calls another CGI program (sign.cgi), which uses PGP to sign the cookies with the role server’s private key.
- The “set-cookie.cgi” then creates the Seal_Cookie, which includes the digital signature of the role server on the contents of the cookies.
- Finally, the role server sends the HTTP response header, along with the set of secure cookies, back to the user’s browser, where the cookies are then stored until they expire.
Secure cookie verification
- The two IP addresses, one from the IP cookie and the other from the environment variable, REMOTE_ADDR, are compared. If they are identical, then the host-based authentication is passed and a hidden field “status” with the “IP-passed” value is created to indicate that this stage was passed.
- The first thing the “password-ver.cgi” does is to check the hidden field “status” to see if the previous stage was successfully completed. If this is “IP-passed,” the program decrypts the value of the Pswd_Cookie (encrypted user password) using the PGP with the Web server’s private key. The program then compares the password from the user and the one decrypted from the Pswd_Cookie. If they are identical, then the user-based authentication is passed, and a hidden field “status” with the value of “password-passed” is created to indicate that this stage was passed.
- If the value is “password-passed,” then the program verifies the signature in the Seal_Cookie with the role server’s public key using PGP. If the integrity is verified, it means that the cookies have not been altered, and a hidden field “status” with the value “verify-passed” is created to indicate that this stage was passed and forwarded to the final program, “rbac.cgi.” This program uses the role information in the Role_Cookie for RBAC in the Web server.
Smart certificates
Public-key certificate (X.509)
A public-key certificate is digitally signed by a certificate authority (CA) to confirm that the identity or other information in the certificate belongs to the holder (subject) of the corresponding private key.
An X.509 certificate consists of the following:
- version of a certificate format
- certificate serial number
- subject’s X.500 name (assigned by a naming authority)
- subject’s public key and algorithm information
- validity period (beginning and end dates)
- issuer’s X.500 name (certificate authority)
- optional fields to provide unique identifiers for subject and issuer (Version 2)
- extensions (Version 3)
- digital signature of the certificate authority
- An attribute certificate binds attribute information to the certificate’s subject.
- Anyone can define and register attribute types and use them for his or her purposes.
- The certificate is digitally signed and issued by an attribute authority. Furthermore, an attribute certificate is managed in the same way as an X.509 certificate.
- However, an attribute certificate does not contain a public key. Therefore, an attribute certificate needs to be used in conjunction with authentication services, such as another certificate (X.509) and SSL, to verify the subject of the attribute.
Smart certificate overview
It is technically possible for certificate authorities to simply issue a certificate that includes the subject’s identity (e.g., public-key information) and attributes (e.g., roles) in the same certificate.
- However, the lifetime of the identity (public key) in the certificate may be different from that of other attributes (roles) in it.
- Furthermore, an organizational policy usually requires different authorities for maintaining attributes and public keys.
- After a public-key authority (basic CA) issues an X.509 basic certificate for a user, Alice, an attribute authority (for instance, Att_1_CA) adds attributes for Alice to an extension field of the basic certificate (which contains public-key information).
- Consequently, the attribute authority (Att_1_CA) signs on the basic certificate and the attributes the authority added and puts the signature to another extension field in the basic certificate.
- This can happen multiple times on a basic certificate by different attribute authorities.
- Later, another party, say Bob, verifies Alice’s identity first by the basic CA’s signature in the smart certificate. If the authentication is successful, Bob verifies Alice’s attributes by the corresponding attribute authority’s signature in the extension field.
- The contents of the attribute information in a smart certificate depend on applications.
- The public key and the attributes can be maintained independently. For instance, even though Alice’s attributes issued by her school-attribute authority expired (were revoked) in the certificate, the rest of the attributes, such as those issued by her company-attribute authority and public-key information in her basic certificate, are still valid.
Using smart certificates
- She first connects to the role server at the beginning of the session.
- After the role server authenticates Alice, it finds her explicitly assigned roles in the URA (user-role assignment) database and creates a smart certificate (which holds her explicitly assigned roles).
- Then, the smart certificate is sent to and stored in Alice’s machine—which has Alice’s private key corresponding to the smart certificate—so that Alice does not need to go back to the role server to obtain her assigned roles until the certificate expires.
- In this particular implementation, we used the OU (organization unit) field in X.509 certificates to store each subject’s role information, and both identity and roles are signed by a single certificate authority. (other implementations may be done)
- When Alice requests access to a Web server, the browser and Web server authenticate each other over SSL.
- After the browser receives and verifies the server’s X.509 certificate, Alice needs to select a proper smart certificate—which has her role information—and send it to the Web server.
- The Web server authenticates Alice by verifying the smart certificate. If the smart certificate is valid and successfully verified, the Web server trusts the role information in the certificate and uses it for RBAC with a role hierarchy and PRA information in the Web server.
- one role for every member in team (project_lead1 for team 1, project_lead2 for team 2, etc)
- inelegant, inefficient
LDAP
Using LDAP
- A client presents her authentication information to a Web server.
- The Web server authenticates the user using a proper authentication mechanism.
- Once a user is successfully authenticated by the Web server (otherwise the user gets an error message), the Web server triggers the CGI (common gateway interface) scripts that call the LDAP client software.
- The LDAP software sends a search query to the LDAP server, which retrieves the user’s roles from the directory server through SSL. The retrieved roles are sent back to the LDAP client in the Web server during the same SSL session.
- When the user requests an access to the resources that require particular roles to be accessed, the Web server compares the user’s roles (which it pulled from the role server) with the ones in its PRA table.
- If the user has corresponding roles in the table, the Web server allows the user to access the resources.
Comparison of user-pull and server pull architectures
user-pull
- enhances Web server performance
- once the user obtains her roles, she can use them in many different sessions, and even in different Web servers, until the roles expire; this increases reusability
- requires a user’s cooperation to obtain her roles
- the longevity of the roles decreases their freshness; if the user already pulled her roles, the updated version in the role server would not become effective instantly.
- Consequently, an additional synchronization process is required. Hence the role server should push the status change in user roles, such as role revocation, to the Web server for updated information.
- user-pull architecture is a good solution for applications where the users’ convenience is required for maintaining and using their roles frequently in diverse Web sites
- requires the Web server’s cooperation for obtaining the user’s role information from the role server
- In this architecture, the Web server retrieves the user’s role information from the role server for each session. This increases the freshness of the roles, so the information update (e.g., role revocation) is more efficient than user-pull architecture
- decreases reusability and increases the single-point failure vulnerability
- server-pull architecture is a good solution for applications where dynamic role update is critical
Related work
getAccess
- released by enCommerce
- uses encrypted cookies, but there is substantial difference between this and secure cookies
- their encrypted cookies are not stored in the user’s machine after the session
- in other words, if a session is ended by closing the browser, the encrypted cookies disappear
- this means that whenever a user, Alice, needs to connect to a Web server with her roles, she must connect to the registry server through the access server first
- released by Siemens Nixdorf
- combines elements from both Siemen’s SESAME and Kerberos
- provides a single list of users on its central domain security server and assigns roles to the users
- however, to use TrustedWeb, the client’s browser needs specific software installed in the client’s machine to communicate with the TrustedWeb servers in the Intranet
No comments:
Post a Comment