Core Security Patterns Weblog

In a typical Single Sign-On (SSO)/Federation scenario using SAML, the Service Provider (SP) initiates the user authentication request using SAML AuthnRequest assertion with an Identity Provider (IDP). The IDP authenticates the principal and returns a SAML AuthnStatement assertion response confirming the user authentication. If the user is successfully authenticated, the SP is required to have the subject’s profile attributes of the authenticated principal for making local authorization decisions. To obtain the subject’s profile attributes (ex. organization, email, role), the SP initiates a SAML AttributeQuery request with the target IDP.  The IDP returns a response SAML AttributeStatement assertion listing the name of the attributes and the associated values.  Using the subject’s profile attributes, the SP can perform authorization operations.

Ofcourse, it looks simple…here is the complexity – Last two weeks I spent on building a Proof-of-Concept that conforms to HSPD-12 Back-end Attribute Exchange specifications and SAMLv2 Attribute Sharing Profile for X.509 Authentication based systems (Both specifications are mandated as part of Federal Identity, Credential and Access Management (ICAM) initiative of Federal CIO Council).  I had been experimenting with an Identity Federation scenario that makes use of Smartcard/PKI credentials – Card Authentication Key (CAK)/X.509 Certificate on a PIV card authenticates a PKI provider (using OCSP) and then using its X.509 credential attributes (Subject DN) for looking up off-card user attributes from an IDP (that acts as an Attribute Authority). The IDP provides the user profile attribute information to the requesting SP. In simpler terms, the SP initiated X.509 authentication directly  via OCSP request/response with a Certificate Validation Authority (VA) of a Certificate Authority (CA). Upon successful authentication, the SP  initiates a SAML AttributeQuery to the IDP (which acts as an Attribute Authority), the SAML AttributeQuery uses the SubjectDN of the authenticated principal from the X.509 certificate and requests the IDP to provide the subject’s user profile attributes.

Using Fedlet for SAML X.509 Authentication based Attribute Sharing

SAML Attribute Exchange for X.509 based Authentication

Fedlet is a lightweight SAMLv2 based Service Provider (SP) implementation (currently part of Sun OpenSSO 8.x and sooner to be available in Oracle Identity Federation) for enabling SAMLv2 based Single Sign-On environment. In simpler terms, Fedlet allows an Identity Provider (IDP) to enable an SP that need not have federation implemented. The SP plugs in the Fedlet to a Java/.NET web application and then ready to initiate SAML v2 based SSO authentication, authorization and attribute exchanges.  A Fedlet installed and configured with a SP can set up to use multiple IDPs where select IDPs can acts as Attribute Authorities. In this case, the Fedlet need to update its configuration with the IDP Metadata configuration (such as entity ID, IDP Meta Alias, Attribute Authority Meta Alias – same as IDP ). In addition, the Fedlets are capable of performing XML signature verification and decryption of responses from the IDP must identify the alias of signing and encryption certificates.

Here is the quick documentation, which I referred  for putting together the solution using Fedlets for SAMLv2 Attribute Sharing for X.509 based authentication scenarios. In case, if you want your Service Provider to use OpenSSO for PIV/CAC based certificate authentication, you may refer to my earlier entry on Smartcard/PKI authentication based SSO (Using OpenSSO). Besides that you should be good to test-drive your excercise. Ofcourse, you can use Fedlets for Microsoft .NET service providers but it was’nt in my scope of work !

In case of SP requiring to fetch multiple user profile attributes you may also choose to use SPML based queries (SPML Lookup/Update/Batch Request/Response) to an Identity Manager (acting as Attribute Authority) – assuming it facilitates an SPML implementation). If you are looking for a solution that requires user profile attributes after a single-user X.509 authentication, then SAML Attribute query should help fetching a single user profile of an authenticated principal !

Life goes on… as everyone know by now, EU approved the Oracle’s Sun acquisition deal.

After my 10+ years long saga ending at Sun…..now I am pushed into Oracle (Sun + Oracle).  It looks like I will be doing the same job….as always I continue my passion towards security and identity technologies… especially on Solaris and Sun systems (oops…Oracle servers)… maybe a bit more on Oracle software stack.

Sun Memorial by James Gosling

The untold reality is ….when your Web application on the DMZ hits the Internet… the colorful performance graphs/numbers does’nt mean anything !  Unless your performance guru in the lab captured the QoS requirements and realized it proactively and accounted its actual overheads associated with Security, Network bandwidth, High-availability and other mission-critical requirements.  Otherwise…performance is the nagging issue that every datacenter guy gnaws…. when an application bloats up with its cryptograhic shields such as SSL  and WS-Security and then goes into production.   If you are one of them in the datacenter, who is pulling the hair out on Security performance issues and compelled to meet the SLA including IT Security and compliance requirements mandating the use of cryptography for securing the exposed application layers  – transport, data and network – Then this Sun solution blueprint should help you for accelerating the real-world performance of Java EE based Web applications (especially Oracle Weblogic) delivering Security ground-up and all WITHOUT  your performance engineer help   :-)

No magic or surprises – The Sun CMT server features On-chip Cryptography and multi-threaded 10GbE networking out of the box – No kidding! If you are curious to know more or seize the power of your Sun CMT servers for security, take a look at the blueprint and also take a look at my previous post highlighting our presentation at Oracle Open World -  Wire-speed Cryptographic Acceleration for SOA and Java EE Security.

Time flies..it is amazing to know, yesterday marked the 15th anniversary of Design Patterns: Elements of Reusable Object-Oriented Software by Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides),  a seminal work in object-oriented software design and development that changed the way how we think and solve software implementation problems. In simpler terms., Design patterns is all about adopting to proven solutions evolved from prior experiences and the known bestpractices/pitfalls without ending up reinvent the wheel ! In my experience, using design patterns helped understanding the architecture and design the software right at the first attempt and resulting reusable code artifacts – easier to reuse with subsequent design and development process.

When Chris and I started our security patterns work… unthinkably..the GoF patterns and its core principles has always been our primary source of guidance for evolving the Security Patterns catalog.  With 14+ years passed by, the Design patterns book has never gone out off my sight and always remained in my reaching distance… when so many other books collecting dust in my shelf !  Now, my shameless promotion… about celebrating the 15th anniversary of Design Patterns - Prentice Hall/Addison Wesley is bringing out a series of interviews (featuring GoF and others), articles and takes this opportuntity to further influencing the relevance of Design patterns books with 30% off on the cover price.. Here you go:

Enjoy…

Last few weeks, I have been pulled into an interesting gig for demonstrating security for _____  SOA/XML Web Services and Java EE applications…. so I had a chance to play with some untold security features of Solaris 10. KSSL is one of the unsung yet powerful security features of Solaris 10.  As the name identifies, KSSL is a Solaris Kernel Module that helps representing server-side SSL protocol to help offloading operations such as SSL/TLS based communication, SSL/TLS termination and reverse-proxying for enduser applications. KSSL takes advantage of Solaris Cryptographic Framework (SCF), to act as an SSL proxy server performing complete SSL handshake processing in the Solaris Kernel and also using the underlying hardware cryptographic providers (SSL accelerators, PKCS11 Keystores and HSMs) to enable SSL acceleration and supporting secure key storage.

Before I jump into how to use KSSL for offloading SSL operations, here is some compelling aspects you may want to know:

1. Helps non-intrusively introduce an SSL proxy server for Web servers, Java EE application servers and also applications that does’nt implement SSL.
2. KSSL proxy listens to all secured requests on the designated SSL port (ex. HTTPS://:443)  and renders a cleartext traffic via reverse proxy (ex. HTTP://:8080) port for the underlying Web or application server. All SSL operations including the SSL handshake and session state are performed asynchronously in the Solaris Kernel and without the knowledge of the target application server.
3. KSSL automatically uses SCF for offloading operations to underlying hardware cryptographic providers with no extra effort needed.
4. Manages all the SSL certificates independently supporting most standard formats (ex. PKCS12, PEM),  the key artifacts can be stored in a flatfile or a PKCS11 conformant keystore (If you are worried about loosing the private key).
5. Supports the use Solaris zones, where each IP identified zone can be configured with a KSSL proxy
6. Delivers 25% – 35% faster SSL performance in comparison with traditional SSL configurations of most popular Web servers and Java EE application servers.
7. KSSL can be used to delegate Transport-layer security and the applications may choose to implement WS-Security mechanisms for message-layer security.

Those are some compelling aspects of KSSL that are hard to ignore…. if you really understand the pain from performance overheads associated with SSL/TLS   As I verified, KSSL works well with most common Web servers and Java EE applications servers.

Try it yourself

Certainly it is worth a try…and you should able to do it very quickly than configuring SSL for your web sever !

• Obtain your server SSL and CA certificates. If you just want to test-drive KSSL and considering to using a self-signed OpenSSL certificate.. just follow the example commands and make sure that your web server hostname is correct. If you choose to use a flatfile based SSL keystore, KSSL requires to have all your certificate artifacts (including private key and certificates) in a single file.  If you need more OpenSSL help, read my earlier post.

          Ex. To create a self-signed server certificate using OpenSSL (in PEM format).

    openssl req -x509 -nodes  -days 365 -subj

     "/C=US/ST=Massachusetts/L=Burlington/CN=myhostname"

    -newkey rsa:1024  -keyout myServerSSLkey.pem -out mySelfSSLcert.pem

           Ex.  Concatenate the server certificates in a single file.

    cat mySelfSSLcert.pem myServerSSLkey.pem > mySSLCert.pem

• Configure the KSSL proxy service,  assuming the secured requests are forwarded to an SSL port (ex. 443) and the reverse-proxy of your backend Web server listens to a non-SSL port (ex. 8080). Use -f option to identify the certificate fomat, to represent PEM (-f pem) and to represent PKCS12 (-f pk12).  If the certificates are located in a HSM/PKCS11 Keystore, use -f pkcs11 to identify the token directory, -T to identify the token label and -C to identify the certificate_subject.

          Ex. To configure the KSSL proxy service with SSL Port 443 and reverse-proxy port is 8080 using PEM based certificates and the passphrase stored in file (ex. password_file).

           ksslcfg create -f pem -i mySSLCert.pem -x 8080 -p password_file webserver_hostname 443

• Verify the KSSL proxy service under Solaris Service Management Framework (SMF) controls, the KSSL services is identified with FMRI svcs:/network/ssl/proxy.

                    svcs - a | grep "kssl"

•  Assuming your webserver in the backend listens at port 8080, you should able to test the SSL configuration provided by the KSSL proxy.  Open your browser, goto https://webserver_host:443/ you should be prompted by the SSL dialog warning to accept a self-signed certificate.

• More importantly, if your Solaris host is a Sun CMT server (based on UltraSPARC T1/T2 processor), KSSL automatically takes advantage of the cryptographic acceleration and no additional configuration is necessary.

Here is an unofficial benchmark that highlights performance comparisons with KSSL and other SSL options.  The following shows the latency of an Web application running on Oracle Weblogic server using different SSL configurations (Certificate using RSA 1024) on a Sun CMT server (T5440) – To interpret the graph, make a note “Smaller the Latency means Faster”.

Adopting to Sun CMT servers (based on UltraSPARC T1/T2 processors) helps delivering on-chip cryptographic acceleration for supporting SSL/TLS and its cryptographic functions. With KSSL based SSL deployment, you will atleast get an additional 30% performance advantage while comparing with other Web server based SSL deployments. I heard that Intel Nehalem EX processors are expected to provide similar on-chip crypto capabilities, not sure !  Either way, using KSSL is a no brainer and it works.  If you are itching the head to provide transport-layer security for your applications, this could be easiest way to go !  Ofcourse, it can help you score some points in those IT infrastructure security assessment checklists verifying for PCI-DSS, FISMA, HIPPA and/or similar regulatory/industry compliance mandates !  :-)

FIPS-140* compliance has gained overwhelming attention these days and it has become a mandatory requirement for several security sensitive applications (mostly in Government and Security solutions and recently with select finance industry solutions and particularly for achieving compliance with regulatory mandates such as PCI DSS, FISMA, HIPPA, etc ). FIPS-140 also helps defining security requirements for supporting integration with cryptographic hardware and software tokens.  Ensuring FIPS compliance to Java based application security has been one of demanding needs of security enthusiasts but unfortunately neither Sun JCE or JSSE is not yet FIPS-140 certified – hopefully soon !  Sun JDK 6 (and above) has also introduced several enhancements including support for enabling FIPS-140 compliance for Sun JSSE using FIPS-140 certified cryptographic providers for supporting SSL/TLS communication and associated cryptographic operations. To accomplish this, Java 6 uses the PKCS#11 support for JSSE to integrate with PKCS#11 based FIPS-140 cryptographic token.

Lately I worked on a security solution using SunJSSE with NSS as a software cryptographic token… and here is my tipsheet for those keen on playing FIPS conformance with SunJSSE.

• SunJSSE can be configured to run on FIPS-140 compliant mode as long as it uses a FIPS-140 certified cryptographic hardware or software provider that implements all cryptographic algorithms required by JSSE  (ex. Network Security Services – NSS, Sun Cryptographic Accelerator 6000, nCipher, etc).

• To enable FIPS mode, edit the file ${java.home}/lib/security/java.security and modify the line that lists com.sun.net.ssl.internal.ssl.Provider and associate the name of the FIPS-140 cryptographic provider (ex. SunPKCS11-NSS). The name of the provider is a string that concatenates the prefix SunPKCS11- with the name of the specified PKCS#11 provider in its configuration file.

                            security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

• In case of using NSS as cryptographic software token (Make use of NSS 3.1.1. or above), assuming the libraries are located under the /opt/nss/lib directory and its key database files  (with the suffix .db) are under the /opt/nss/fipsdb directory, the sample configuration for representing NSS will be as follows:

• In FIPS mode, SunJSSE will perform SSL/TLS 1.0 based communication and cryptographic operations including symmetric and asymmetric encryption, signature generation and verification, message digests and message authentication codes, key generation and key derivation, random number generation, etc.
• To refer to the SunJSSE supported Ciphersuites suites refer to the Sun JSSE’s documentation and notes for FIPS guidance.

One thing I noticed lately…is lot of interest about understanding the usage of ‘Obfuscated Transfer Object (OTO) ‘ from Core Security Patterns.  I got multiple emails about its code and implementation .. understandably there is a growing security concern about using Transfer Object (aka Value Object) that passes security-sensitive data elements between Java EE tiers (especially between Presentation/Business/Persistence), when the application components does’nt run in a co-existing environment and risks associated with getting captured in console messages, log files and by rogue administrators. Think about “User Profile” or “Credit Card” or any other sensitive data in transit, it becomes quite critical to ensure privy of the data with appropriate data protection in place.  When we wrote Core Security Patterns, Chris and I discussed more  about this pattern and its implementation than anything else….agreed, this has its own implementation complexities . The worst you could see is, if you screw up the implementation it masks all the Java EE components from consuming the data elements of the passed OTO…. from a security perspective, it is a good thing as it fails safely.

Let’s dig into the finer details of why and how you would choose to implement an Obfuscated Transfer Object:

Why OTO ?

• To protect sensitive data passed in Transfer Objects from being captured in console messages (JMX, Adminstration), log files and audit logs.
• To ensure Transfer object be responsible for protecting the data and prevent target application components from inadverently exposing sensitive data.
• To protect select data elements and not all data elements should be protected or exposed.

How it works ?

In simpler terms, Obfuscated Transfer Object allows  to define data elements within it that are to be protected using mechanisms to prevent purposeful or inadvertent unauthorized access to its data. The means of protection can vary between applications or implementations depending on your target business requirements. The OTO provides the producers and consumers of the data can agree upon the sensitive data
elements that need to be protected and on their means of access. OTO will then take the responsibility of protecting that data from any intervening components that it is passed to on its way between producer and consumer. For example, Credit card and other sensitive information can be protected from being accidentally dumped to a log file or audit trail, or worse, such as being captured and stored for malicious purposes.

How to Implement OTO ?

Although there are several ways to implement OTO, the two easier ways we found to implement OTO are  Masked List Strategy and Sealed Object/Encryption Strategy.

Masked List Strategy

In this strategy, the client sets data as name-value (NV) pairs in the Obfuscated Transfer Object. Internally, the Obfuscated Transfer Object maintains two maps, one for holding NV pairs that should be obfuscated and another for NV pairs that do not require obfuscation. In addition to the two maps, the Obfuscated Transfer Object contains a list of NV pair names that should be protected. Data passed in with names corresponding to names in the masked list, are placed in the map for the obfuscated data. This map is then protected. In the sequence above, when the Component logs the ObfuscatedTransferObject, the data in the obfuscated map is not logged, and thus it is protected.

Sealed Object/Encryption Strategy

With encryption Strategy for Obfuscated Transfer Object provides the highest level of protection for the data elements protected within. The data elements are stored in a Data Map, and then the Data Map as a whole is encrypted using a symmetric key. To retrieve the Data Map and the elements within it, the consumer must supply a symmetric key identical to the one used by the producer to seal the Data Map.

private SealedObject sealedMap;

// Seal object

HashMap map = sealedMap.getObject(cipher);

// Unseal object

sealedMap = new SealedObject(map, cipher);

As shown above, we can implement this using Java Sealed Object class that allows to easily encrypt objects by passing in a serialized object and a Cipher object in the constructor. The serialized object can then be retrieved by either passing in an identical Cipher or a Key object that can be used to recreate the Cipher. This encapsulates all of the underlying work associated with encrypting and decrypting objects. The only issue remaining is the management of symmetric keys within the application. This poses a significant challenge because it requires the producers and consumers to share symmetric keys without providing any intermediary components with access to those keys. This may be simple or overwhelmingly complex depending on the architecture of the application and the structure of the component trust model. Use this strategy with caution, because the key-management issues may be harder to overcome than architecting the application again to eliminate the need for the Sealed Object .

Hope this helped my two EU friends…who keep pestering me last two days via email. Due to my contractual obligations with Prentice Hall, I cannot dump the contents and source code in my blog…so I leave the rest to your way and you know where to look for . Also don’t ask how it is being implemented in Microsoft .NET – that’s not my forte.