January 28, 2011

Introducing UnboundID Server SDK - Future-proof your investment

Rationale
UnboundID released the UnboundID Server SDK to future proof your investment in your technology choice for your identity and application data. There will always be something new the business has to react to, a new device that didn't exist 18 months ago your identity platform will absolutely need to support to make the targets, a new application you must bring to market within the quarter, unforeseeable things when making a decision on the technology to use for your platform. But there is one thing that you can chose: a technology partner that will commercially support you with your growing and changing needs, a product line that can grow with you and shoulder the complexity of keeping pace with innovation.


The Meat
The Server SDK is a Development Kit for all UnboundID current and coming products, empowering organization with great control on their most precious asset and industrial tool: the application data store and identity repository. It allows to extend and enrich the functionality of the products with custom tailored business logic to better interact with existing systems or simply deliver functionality needed closest to the data.


So in short, the UnboundID Server SDK brings an unprecedented tool in the IT architect's tool box. A tool that changes everything. You don't have to architect a monolithic platform that is so rigid your applications development teams have to do all the hard work of keeping your organization nimble and your business in the race with a competitive market place. You can rationalize this into the platform, by providing a rock solid, near real time platform that can adapt to new demands.


This is especially important when organizations typically have hundreds of applications, all with different needs and uses for the data, tapping in one common infrastructure for rapidly changing data like location, presence, identity (authentication, authorization) and such.


Let the platform do it, save on development costs by factoring changes in one central trusted place. Instead of having to modify each application when an enhancement is needed, which is often the case today, let the platform handle it. The platform naturally brings features that would be costly to implement in each application, most notably: distribution of data, security policies including authentication and authorization but also data encryption, tamper detection, reliable replication, breach detection and notification.
You need a single entity to manage all these aspects to let each application focus on the added value they bring to the business, the end user or the customer.


I'm going to use two examples to illustrate how powerful controlling the platform is:

  • Coming up to the recent events in Tunisia, Facebook realized that the government of Tunisia was eavesdropping (an eve attack in crypto parlance) in order to get Tunisian Facebook users credentials that they would later use to delete the user's account. Because Facebook has written their platform from the ground up, they have absolute control over it, they could quickly react to this new situation by introducing a new connection policy (forcing HTTPS) and a new password policy (requesting users to identify friends from their network in a social captcha-like scheme). All that with no interruption of service or any inconvenience to users anywhere.
  • A banking institution operates a large identity infrastructure serving both customers and collaborators. Among rising concerns, they decide to implement a new feature for their customers: a one-time-password that they can use when in riskier than usual situations (checking balances over an airport free wifi hotspot for example). They do so by writing the adequate extension and rolling it out without taking the service down. Not only customers are not inconvenienced but all the applications they know and love immediately benefit from the new feature without a single change on their part: everything is still the same from where they sit. Additionally, the banking institution implements a 2-factor extension for collaborators, once again, the usual tools they have to use remain unchanged, avoiding costly and lengthy internal staff trainings.
These are just two examples. There are a lot more.

I hear the open-source supporters say: "Well with open source software, I control the platform since I have the source, I can do anything I want!"

While this is true in absolute, stop a second and ask yourself: 
  • does my team actually have the knowledge required?
    In many cases, open source software comes with support only for vetted releases, any alterations and you are on your own. Also, without a clean interface to build extensions to the core product, you may need to delve into the product more than you may want. Do you have the time to learn the product THIS well? The want? When an organization gets to this level of involvement in an open source project, it often means that they become contributor to the project and have resources on staff dedicated to it. Bang goes the cost... it just exploded.
  • Where can I get commercial support for my much needed extension?
    For those open source projects that offer commercial support, you can only get the extension covered by its own commercial support if it has been developed by the company backing the open source project.
  • Indemnification?
    I will let yo make up your own mind on that.
So how is UnboundID Server SDK different?

  • Extension can be written by any organization's staff having undergone our qualification and training.
  • Writing extensions, as you will see in upcoming posts is very easy. You may write extensions achieving powerful features that the business may have delayed projects for in the past in as little as a week with testing a sandbox roll-outs. The complexity of the core is well insulated inside the core, the API to enhance the server shields the developer from it.
  • Extensions are supported. Period.
  • The Server SDK comes with our products. Use it to extend any product to do nearly anything you'd like.



Controling the platform is a great business enabler, as Google and Facebook can attest, and that's precisely what UnboundID brings to the identity sphere with its Server SDK.


Get it.


The official UnboundID Server SDK page can be found here.

January 24, 2011

Bullet Proofing UnboundID DS - part 2: Securing Connections

Rationale
the rationale is pretty straightforward here, you want to secure connections from clients to your infrastructure in an effort to reduce risk of compromising access.
The Meat
  The flow
This helps understand how we will secure the connection without compromising the user credentials: the credentials actually get transmitted through the connection AFTER it has been secured with TLS, which is the whole point honestly.


Now comes the trick: It means we cannot completely block out unencrypted connections or it will mean the startTLS extended operation cannot be transmitted. Because the connection has to be initially unsecure, what we can do though is to only allow a BIND to come in with the startTLS operation. Any thing else will bounce but the startTLS extended operation to secure the connection.
It will look like this:
Now the "secure" connection handler will allow any operation for an authenticated user over the secured connection.
  How


Here is how:
  1. create a "secure connection" connection criteria that will require secure-only communication, authentication through simple auth, sasl or internal and a secure-only authentication.
  2. create a "secure policy" client connection policy with a priority of 1 referring to the "secure connection" connection criteria
  3. update the the "default" client connection policy to only allow Bind and Extended operations and extended operation OID 1.3.6.1.4.1.1466.20037
Here is how to do it through our 3.0.0 GUI:




here is how to do it through our dsconfig CLI:







and finally, here are the dsconfig commands achieving the same result (from config-audit.log):

# Undo command: dsconfig delete-connection-criteria --criteria-name "secure connection"
dsconfig create-connection-criteria --criteria-name "secure connection" --type simple --set communication-security-level:secure-only --set user-auth-type:internal --set user-auth-type:sasl --set user-auth-type:simple --set authentication-security-level:secure-only


# Undo command: dsconfig delete-client-connection-policy --policy-name "secure policy"
dsconfig create-client-connection-policy --policy-name "secure policy" --set enabled:true --set evaluation-order-index:1 --set "connection-criteria:secure connection"


# Undo command: dsconfig set-client-connection-policy-prop --policy-name default --add allowed-operation:abandon --add allowed-operation:add --add allowed-operation:compare --add allowed-operation:delete --add allowed-operation:modify --add allowed-operation:modify-dn --add allowed-operation:search --remove allowed-extended-operation:1.3.6.1.4.1.1466.20037
dsconfig set-client-connection-policy-prop --policy-name default --remove allowed-operation:abandon --remove allowed-operation:add --remove allowed-operation:compare --remove allowed-operation:delete --remove allowed-operation:modify --remove allowed-operation:modify-dn --remove allowed-operation:search --add allowed-extended-operation:1.3.6.1.4.1.1466.20037

January 18, 2011

Bullet Proofing UnboundID DS - part 1: Certificates

Rationale
We're in the business of making you safe. Here is a quick step by step guide to making your authoritative source of authentication and authorization so safe it will bring peace and tranquility to CIOs and CTOs across the globe.
The Meat
  1. TLS vs SSL
    I am only going to cover TLS here because I believe it is going to be the most useful. In fact, while there are arguments going for SSL, TLS is better. Security wise, the encryption is the same. As a matter of fact, SSL and TLS are the same very thing. The difference here is that SSL implies that the connection be encrypted and then LDAP traffic is carried over the encrypted link. With TLS, a connection is established to the directory server and then, at the client's request, its security can be elevated to a TLS encrypted one with the cunning use of the startTLS extended operation. This means that TLS allows the flexibility to go to and from a secure environment based on mutual agreement by both the server and the client. This means that clients only need to know a single port for both secure and insecure transactions. It greatly simplifies deployment and maintenance, and that too counts as part of improved security.
  2. Certificates
    Dealing with certificates certainly seems like the biggest hurdle to most people that have to go about securing their environment. In the enterprise, this always means that you need your own PKI. For now, I will just show how trivial it is to get started.
    1. Server Side
      1. choose a password and store it in a read protected file
        echo password1 > key.pwd
        echo password2 > keystore.pwd
        echo password3 > truststore.pwd
        chmod 400 *.pwd
      2. generate a key pair for the server
        #keytool -genkeypair -keyalg RSA -keysize 2048 -keypass password1 -alias server -keystore server.keystore -storepass password2
      3. export the server public key
        We will need the public key later to add it in the trust store on the client side.
        #keytool -exportcert -alias server -keystore server.keystore -storepass password2 -file server.cer
      4. generate a certificate signature request
        #keytool -certreq -alias server -keystore server.keystore -storepass password2 -keypass password1 -file server.csr
      5. submit the csr to your certificate authority (CA), you will get a signed certificate in return and to install it simply import it with the same alias as when you created the key pair
        #keytool -importcert -alias server -keystore server.keystore -storepass password2 -file yoursignedservercertificate.cer
      6. We will now create a trust store. The trust store is usually a good place to store the public keys that you trust and allows you to avoid polluting your keystore. Your key store contains private information. Your trust store contains information that is public. It allows for a clean separation of duties. You can also share your trust store on an NFS share to make it available to all servers while typically the key store would be more protected and specific to each server. In the example below, we create a trust store containing the public key for our CA and intermediate CA:
        #keytool -importcert -alias ca -keystore server.truststore -storepass password3 -file ca.cer #keytool -importcert -alias intermediateca -keystore server.truststore -storepass password3 -file intermediateca.cer
    2. Client Side
      Here it is much simpler, we will simply generate a self-signed certificate on the client side. Here's how:
      #keytool -genkey -alias client -keystore client.keystore -keyalg RSA -keysize 2048 -storepass password4 -keypass password4

      and now let's export the public key so we can later import it in the server trust store:
      #keytool -exportcert -alias client -keystore client.keystore -storepass password4 -file client.cer
    3. Mutual trust
      Here's how the server knows to trust the client and vice-versa. We need to import the client public key in the server trust store and the server public key in the client trust store.
      1. Server Side
        #keytool -importcert -alias client -keystore server.truststore -storepass password3 -file client.cer
      2. Client Side
        #keytool -importcert -alias server -keystore client.truststore -storepass password5 -file server.cer