End Dating an account in Linux

Often times we want to terminate an Linux account for security reasons. Below command can be used to do the same

/usr/sbin/usermod -e

This option (-e) can also be used when account is originally created. This gives extra security if you already know when the person will be out of the project.

Keep in mind that 70-80 % of hacking is internal in the organization.

Strong Authentication

In today's world when more and more applications are getting consolidated in enterprise portals we have to have a solution to protect secure applications with extra layer of protection. Strong authentication or multilayer authentication is the solution for this problem. Let me give a brief introduction about different ways in which we can authenticate ourselves

1) What we Know : UserId, "secure PIN", Password, Security question/answer

2) What we Have : "Secure token", "Bank ATM card"

3) What we Are : Biometrics

Normally we use userid/password combination to get into any secure site. That authentication mechanism is secure but only to certain extent.

Take an example where you are authenticating to a bank site using userid/password combination and someone on the network (Man in the Middle) captures your userid/password. He can use those credentials to get into the banking network .....(you know what I am thinking here). It seems to be very complicated on the board but people have done it and our goal is to reduce those attacks to the maximum possible extent.

If we introduce one more layer of authentication in the authentication logic by adding 2) or 3) from the above, we will make the system more secure because Man in the Middle will not have what you have and definitely he can not be You. This is called strong authentication.

There are various ways to introduce second factor, one such mechanism is One Time Password (OTP). In OTP system generated password can be used only once so even if that password is trapped over the network it can not be used again.

Refer to RFC for getting more inside of OTP. There are many products available in the market for OTP. Apache is also working to build one such system under the name of triplesec http://directory.apache.org/triplesec/

Technorati : Multifactor Authentication, Strong Authentication

Virtual Directory pros and cons

Virtual Directory is a concept in which application/product providing this functionality does not store any data. It is just a representation of the global data spreaded across an organization into a single place. These products can aggregate the data from directory servers, databases, data coming from applications over web service interface etc. Data coming from the Databases can also be exposed over an LDAP interface.

Main feature is to get the data and provide the consolidated data to the end application. Advantage of this is to reduce the calls to individual systems if they are storing different set of data. For example if Directory Server has user information and Database stores the role information then a common view can be exposed to the end application via which end application can have access to the whole data in one request. Applications don't need to make individual calls to different repositories to get the data.

Keep in mind that Virtual Directories does not store any data on it's own and it does not update data change from one system to the other system. There job is just to gather all the data under one roof for easy access to the applications.

Another advantage of Virtual directory could be to restrict the access to the data. If you give control of the organization directory server to an application then you can not restrict the application to read only first and last name of the person. If application has the access it has access to all the attributes. With Virtual Directory you can restrict access to the data you want application to see.

Interface: Virtual Directory products expose there propritory API's which applications can use to have access to the systems. Since Virtual directories does not store information locally there could be performance issues getting the data from the backend repositories.
Caching problem: If someone says that to overcome the performance issue we can cache the data locally at the virual directory then next question would be how to synch the data which is updated at the backend repository by another application?

Complexity of Session Timeout

One of our application team was using the centralized access control product for securing the access to the application. Users of the application team started reporting the timeout issue from the application after some time. We thought that increasing the ideal/session timeout settings should solve this problem. We increased both the values to hours just for testing that if those settings are the culprit. But making that change has not changed the situation. Our next suspect was the application code so we asked the application team to check if code is doing any session timeout after some time. They also confirmed back that is also not the case. We approached the application deployment team and requested them to make the change in the session timeout parameter from the application server. As soon as they changed the session timeout value to unlimited problem was resolved.

My question to myself was how can that application server parameter be responsible for timeout and redirect the user to login page? I read the servlet specification (version 2.3) for this issue and here is what I feel should be happening in this case.

1) User accesses the application page for the first time.

2) Since access control product is used to protect the application user is redirected to the access control login page.

3) User authenticates successfully and redirected to the application.

4) Access control product agent is using the session variable (JSESSIONID) as a key to cache the user details like session expiry, ideal time out etc.

5) User access the application again. This time JSESSIONID is passed from the browser as a cookie to the application/web server. This JSESSIONID is used as a key to look for session information in the access control product agent cache.

6) After the JSESSIONID expiry at the application server, new JSESSIONID is generated and the cookie value is overwritten.

7) User accesses the page again but this time new JSESSIONID value is passed to the application/web server. This new value is again compared in the cache. It will not be found in the cache. Agent will treat this request for a new user and redirects the user to login page.

What value for the session expiry should be set:

For ideal condition JSESSIONID value should be set as the same value for the session timeout from the access control product. If the access control product has session expiry as 1 hour and ideal time out as 30 minutes then application server session expiry should be set to 1 hour.

Technorati : session timeout

Magic Of HTTP Header Variables

Last week I attended one vendor presentation in which presentor was talking about how there product can be installed on the application servers to bypass the login mechanism. In this approach application login page needs some modification. I understood what he was talking about and thought to share this with my friends reading my blog.

Product must be using the magic of HTTP header variables and here are few steps which can be used to make it working

1) As soon as user logs into the centralized access control product it will set a browser coookie for the user.

2) User clicks on the application URL, product agent is sitting at the application/web server.

3) Browser will pass the cookie to the product (Assuming all the applications are running in single cookie domain).

4) Agent will intercept the cookie token and will verify the validity (session timeout/idealtimeout etc) with the centralized server.

5) After validation agent will set the predefined HTTP header variable's in the request and forward the request to the application/web server

6) Application will check if the required header variables are present in the HTTP request or not.

7) If the required header variables are found in the request and internally authorized by the application authorization module requested page will be served to the user. Custom header variables can contain information like username, employ number, job code etc which can be used to decide the authorization rights.

8) If the required HTTP header variables are not found in the request user will be redirected to application login page.

There are many HTTP header variables which are part of the HTTP standards but custom HTTP header variables can be defined based on the requirements. One thing to note in the above scenario is that every time a new page is requested by the user same HTTP header variables needs to be passed to the application as the life of the HTTP header variables is limited to single request.

Technorati : http header