My favorites | Sign in
Project Home Downloads Wiki Issues Source
Project Information
Members
Featured
Downloads
Wiki pages
Links

In the Payment Card Industry (PCI), security is always a major concern. A lot of enterprise applications have application passwords hard-coded in configuration files, which are not allowed by the Payment Card Industry Data Security Standard (PCI DSS). Smart Account Management (SAcct) is a light-weight Security Framework to ease your pain of removing the account passwords from application configuration files. The SAcct server reads in the account information from a secured soft token and acts as an account server. The SAcct client communicates with the SAcct Server over a secured channel to retrieve account passwords on behalf of the application on start-up.

Problems and Challenges

Take a Spring application as an example, the following wiring file includes a database user name and a user password,

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="${jdbc.driverClassName}"/>
        <property name="url" value="${jdbc.url}"/>
        <property name="username" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
        <property name="maxActive" value="100"/>
        <property name="maxWait" value="1000"/>
        <property name="poolPreparedStatements" value="true"/>
        <property name="defaultAutoCommit" value="true"/>
    </bean>

To put the database user password into the configuration file is a serious security problem and it is not allowed by the Payment Card Industry Data Security Standard (PCI DSS). Some frameworks try to encrypt the passwords, but they still need to wire in the encryption password, which does not really solve the problem. We propose to store the accounts in a secured token file, which you can put into a USB drive or other secured devices, then the SAcct framework can retrieve them on behalf of the application during the application start-up phase.

SAcct Architecture

The SAcct architecture is shown in the following diagram,

The SAcct server is a standalone Java application and mainly consists of the following components:

  • Session Manager: create a session key for each connection based on the Diffie-Hellman Key Exchange protocol. It also generates a session id and maintains the sessions in the cache.
  • Account Manager: read account data from the account token file and service client account requests.
  • Connector: read requests from the client and write the responses back to the client. Message encryption/decryption is handled on this layer.

The SAcct client usually is one part of the business application. It derives the session key and stores the session information in a token. The SAcct client also includes a socket connector to communicate with the SAcct server. All request messages are encrypted except the session Id as shown in the system diagram. The communication flows are summarized as follows,

  1. handshake request: The client generates two big numbers, Cr as the private key, Cp as the public key, and initiates the connection by sending the public key Cp to the SAcct server.
  2. handshake response: Upon receiving the client request, the SAcct Server generates its own private key Sr and public key Sp. In the meanwhile, it derives a secret key as the session key based the client's public key Cp and its own keys. Then the SAcct server responds back to the client with its public key Sp and a random session id.
  3. account service request: The client derives the same secret key after received the server's public key Sp and starts to send a secured service request to the server using the session key.
  4. account service response: The SAcct server decrypts the request and replies back the encrypted service response with the session key.
  5. closeSession request: The client finishes its job and sends a closeSession request to the SAcct server.
  6. closeSession response: The SAcct server replies back and the client closes the socket connection.

SAcct Features

SAcct is a Java application and suitable for Enterprise Java applications. SAcct features are highlighted as follows,

  • Light-Weight
  • Use Google Guice as the dependency injection framework for the SAcct Server
  • Account information are encrypted and stored as a soft token on a carry on device
  • Utility tools are provided to encrypt and decrypt the soft token
  • Use the Diffie-Hellman key exchange protocol to derive the session key
  • The communications between the SAcct Server and the SAcct Client are encrypted by the session key
  • An One Time Password (OTP) is used to prevent session replay attack
  • All encryptions use the Advanced Encryption Standard (AES) algorithm
  • Spring support
  • Many security utility classes

SAcct Modules

SAcct consists of the following modules:

  • SAcct Common: common and shared classes between the SAcct server and the SAcct client.
  • SAcct Server: SAcct server is a standalone Java application.
  • SAcct Client: SAcct client acts as a client stub communicate with the SAcct server.
  • SAcct Spring: Utility classes for the Spring framework.
  • Reference Project: will create a reference project to demonstrate how to use SAcct.
  • Account UI: will add UI to manage account tokens.

SAcct Solutions

What to know how SAcct solves the problems? Take a Spring application as an example.

First, you need to download SAcct server, unpack it, go to the bin directory, and run

./sacct_server

The SAcct server will read in the soft token and listen on socket port 9000 by default.

The Account Provider is an abstraction of the SAcct client. In your Spring application, you can define the account provider bean as follows.

    <bean id="accountProvider" class="org.osomit.sacct.provider.impl.spring.AccountProviderFactoryBean">
        <constructor-arg index="0" type="java.lang.String" value="server"/>   <-- Client ID
        <constructor-arg index="1" type="java.lang.String" value="localhost"/>  <-- SAcct Server Host
        <constructor-arg index="2" value="9000"/>    <-- SAcct Server Port
        <constructor-arg index="3" value="false"/>   <-- Wheather to Use One Time Password
        <constructor-arg index="4" value="false"/>   <-- Is active?
    </bean>

The account factory bean is used to retrieve the actual account password information from the account provider. Optionally, you can provide the default/dummy password in the case that the SAcct is not available.

    <bean id="databasepassword" class="org.osomit.sacct.provider.impl.spring.AccountFactoryBean">
        <constructor-arg index="0" ref="accountProvider"/>    <-- Account Provider
        <constructor-arg index="1" value="${jdbc.username}"/>  <-- Account Name
        <constructor-arg index="2" value="defaultDataBasePwD"/>  <-- Account default/dummy password (optional)
    </bean>

Finally, the dataSource bean can be rewritten as

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="${jdbc.driverClassName}"/>
        <property name="url" value="${jdbc.url}"/>
        <property name="username" value="${jdbc.username}"> 
        <property name="password" ref="databasepassword"/>  <-- Provide Data Source Password
        <property name="maxActive" value="100"/>
        <property name="maxWait" value="1000"/>
        <property name="poolPreparedStatements" value="true"/>
        <property name="defaultAutoCommit" value="true"/>
    </bean>

For more details, please read SAcct 0.1.0 User Guide and the FAQs.

Maven Repository

Thanks to Matt Senter, SAcct artfacts are in our Maven repositories now:

For how to use Maven with SAcct, please refer to the Maven guide in the user guide.

Support

If you have any problems, please post to our SAcct User Group, I will get back to you as quick as possible.

If you are interested in contributing to SAcct, please read How to Contribute.

NEWS

Powered by Google Project Hosting