HTTP Basic Authentication


1) HTTP Basic Authentication:

Basic authentication is the simplest protocol available for performing authentication over HTTP. It involves sending a Base 64-encoded username and password within a request header to the server.

A web server/JEE Container requests a web client to authenticate the user. As part of the request, the web server passes the realm (a string) in which the user is to be authenticated. The realm string of Basic Authentication does not have to reflect any particular security policy domain (confusingly also referred to as a realm). The web client obtains the username and the password from the user and transmits them to the web server. The web server then authenticates the user in the specified realm/LDAP-Server.

Working Mechanism:

To understand the details of this protocol let us take example.

Say an unauthorized client tries to access one of our secure RESTful web services:

GET req with URI as /stock/Dell HTTP/1.1

Since the request does not contain any authentication information, the server would reply with an HTTP response of:

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Basic realm="CUSTOMER" Realm

The 401 response tells the client that it is not authorized to access the URI it tried to invoke on. The WWW-Authenticate header specifies which authentication protocol the client should use. In this case, Basic means basic authentication should be used. The realm attribute identifies a collection of secured resources on a website. The client can use the realm information to match against a username and password that is required for this specific URI.

To perform authentication, the client must send a request with the Authorization header set to a Base 64-encoded string of our username and a colon character, followed by the password. If our username is "John" and our password "welcome", the Base 64-encoded string of "john:welcome" will be YmJ1cmtlOmdlaGVpbQ==. Put all this together and our authenticated GET request would look like this:

GET /stock/Dell HTTP/1.1 

Authorization: Basic YmJ1cmtlOmdlaGVpbQ== 

The client needs to send this Authorization header with each and every request it makes to the server.



Problem with this Approach and Solution:

BASIC Authentication is not a secure authentication protocol. User passwords are sent in simple BASE-64 ENCODING (not ENCRYPTED!), and if the target server is not authenticated then Additional protection can alleviate some of these concerns: a secure transport mechanism (HTTPS), or security at the network level (such as the IPSEC protocol or VPN strategies) is applied in some deployment scenarios.

The problem with this approach is that if this request is intercepted by a hostile entity on the network, the hacker can easily obtain the username and password and use it to invoke its own requests. Using an encrypted HTTP connection, HTTPS, solves this problem. With an encrypted connection, a rogue(unprincipled man)/hacker on the network will be unable to decode the transmission and get at the Authorization header. Still, security paranoid network administrators are very squeamish about sending passwords over the network, even if they are encrypted within SSL packets by using this Approach. 

Configuration:

web.xml:

<web-app>

  <security-constraint>

    <web-resource-collection>

      <web-resource-name>User Auth</web-resource-name>

      <url-pattern>/auth/*</url-pattern>

    </web-resource-collection>


    <auth-constraint>

      <role-name>admin</role-name>

      <role-name>manager</role-name>

    </auth-constraint>

  </security-constraint>

  <login-config>

    <auth-method>BASIC</auth-method>

    <realm-name>User Auth</realm-name>

  </login-config>

  <security-role>

    <role-name>admin</role-name>

  </security-role>


  <security-role>

    <role-name>manager</role-name>

  </security-role>

</web-app>

Ads


Post a Comment

3 Comments