I’ve spent the last few days attending Oracle OpenWorld conference at San Francisco..it is my second OOW experience, so it is not a surprise to see the conference was fully packed with people, hundreds of sessions and demos – I did have an opportunity to attend few and also present two sessions focused on Security topics featuring “Hardware Assisted Security Solution for SOA, XML Web Services and Java EE applications” – showcasing how “Hardware and Software Engineered together”.
During the conference, John Fowler – Oracle EVP, Systems announced the industry’s first 16 core processor introducing new SPARC T3 systems with integrated security and virtualization capabilities. Each SPARC T3 processor features 16 on-chip cryptographic accelerators that deliver cryptographic operations running in parallel at CPU speeds and offloading compute-intensive cryptographic functions from software – thus eliminating the need for additional special-purpose cryptographic accelerators such as PCIe cards or network appliances. The cryptographic operation offload and acceleration is accomplished using dedicated cryptographic accelerator drivers, called the Niagara Crypto Provider (NCP), Niagara 2 Crypto Provider (N2CP) and Niagara 2 Random Number Generator (N2RNG). In practice, the NCP and N2CP accelerators uses the Oracle Solaris Cryptographic Framework for enabling user-level applications to off-load cryptographic operations via PKCS#11 standard interfaces and take advantage of NCP and N2CP based on-chip cryptographic acceleration. The current UltraSPARC T3 processors provide acceleration support for public-key encryption mechanisms including RSA, DSA, DH and ECC algorithms, symmetric key-based encryption amechanisms including DES, 3DES, AES and Kasumi algorthms and Message disgest/hashing mechanisms MD5, SHA1, SHA-256 and SHA-512 algorithms. The Solaris Cryptographic Framework (SCF) library plays a vital role for providing applications access to NCP and N2CP accelerators through a set of cryptographic services for kernel-level and user-level consumers. Using PKCS#11 interfaces of Solaris Cryptographic Framework, SOA and Java EE Applications (ex. Oracle Fusion Middleware, WebLogic, Glassfish, JBoss, Websphere) can take advantage of NCP and N2CP based cryptography acceleration (Refer figure).
Both SOA/XML Web services and Java EE based applications can significantly gain on security performance by offloading and delegating their cryptographic operations to the on-chip cryptographic accelerators of Oracle SPARC Enterprise T-Series servers.
To enhance security performance, both the Oracle WebLogic server and Oracle WSM secured applications can offload select cryptographic operations to address the following security scenarios.
Based on a performance study, Oracle’s SPARC Enterprise T3-1 server was used to evaluate both SSL and WS-Security application performance of a SOA/XML Web Services application deployed on Oracle Fusion Middleware (WebLogic 10.3.3 and Oracle Web Services Manager).
Now, you got the highlights, if you are ready to dig deeper on the details and test-drive the solution – Please download and read the following two whitepapers (available from Oracle Technology network) that explores the above solution from ground up.
If you are curious to see the OOW presentation – It is right here.
Thanks to Vikas Jain, Nitin Handa and Chad Prucha for all the help and support on this effort.
Don’t forget to let me know, if you had any comments and suggestions.
When it comes to Java cryptography based application security – Solaris has significant performance advantage over Linux and Windows on Intel Westmere processor equipped servers. I am not debunking Linux performance on Intel but evidently Linux does not take advantage of Intel Westmere’s AES-NI instructions when the Java applications relies on Java cryptographic implementations for performing AES encryption/decryption functions. AES is one of the most popular symmetric-key encryption algorithm widely used in security transaction protocols (SSL/TLS, IPSEC), Disk encryption, Database encryption, XML Web Services security standards (WS-Security) and so forth. If you are a Java security enthusiast or a developer who is curious about Intel Westmere and Java security – here is some observations:
Intel introduced the new 32nm Westmere processors family (Xeon processor 5600 series) that incorporates instructions for AES algorithm (AES-NI) to faster cryptographic applications that uses AES – a symmetric-key encryption standard. AES is a block cipher, with a fixed block size of 128 bits that encrypts and decrypts data using multiple rounds where the number of rounds (10, 12, or 14) depends on the keysize (128, 192 or 256 bits). The Intel’s AES-NI implementation consists of seven new instructions for AES algorithm - AESENC, AESENCLAST, AESDEC, AESDECLAST, CLMUL, AESIMC, and AESKEYGENASSIST to support performing computations for 10 (128 Bit), 12 (192 Bit), and 14 (256 Bit) rounds and most operational modes including ECB, CBC and CTR. AES-NI accelerates AES based encryption/decryption operations in the CPU by offloading them from the software and eliminates its time spent in AES encryption/decryption functions. This means applications relying on AES algorithm can delegate its AES encryption/decryption functions to Intel’s AES-NI. To enable applications make use of Intel AES-NI, it is critical that the applications must be recompiled to use Intel’s Integrated Performance Primitives (Intel IPP) library that contains functions and optimizations for achieving AES performance using AES-NI on Intel Westmere processors. Assuming the applications are recompiled and optimized to include Intel’s IPP library – applications can benefit from AES-NI features of Intel Westmere.
With the release of Solaris 10 Update 8 and above, Solaris 10 introduced support for Intel AES-NI through integration with Solaris Cryptographic Framework (SCF). As Solaris Cryptographic Framework acts as the intermediary for cryptographic operations, all applications relying on Solaris based PKCS#11 provider APIs, CLIs and Solaris kernel modules will automatically take advantage of AES-NI instructions for AES encryption and decryption. More importantly, with AES-NI integration - Java SE/Java EE applications using JDK’s SunPKCS11 provider for supporting Java Cryptographic Extensions (JCE) and Java Secure Socket Extensions (JSSE), applications using OpenSSL with Solaris PKCS11 and Mozilla NSS with Solaris PKCS11 automatically use Intel AES-NI accelerating AES encryption/decryption operations on Solaris.
By default on Solaris, the Sun JDK and its JCE provider environment uses a Sun PKCS#11 implementation (SunPKCS11) that allows Java applications to access Solaris managed software/hardware cryptographic services. The SunPKCS11 provider is a Java based PKCS#11 implementation that integrates with underlying Solaris PKCS#11 implementations provided by the SCF and its exposed cryptographic providers (ex. Intel AES-NI). In a typical JDK installation on Solaris, the Java runtime environment is pre-configured to make use of the SunPKCS11 provider. To verify this refer to the Java security properties file located at $JAVA_HOME/jre/lib/security/java.security properties file and make sure it identifies SunPKCS11 as the default provider.
The $JAVA_HOME/jre/lib/security/sunpkcs11-solaris.cfg file contains the configuration information used by the SunPKCS11 provider for accessing the SCF. To leverage AES-NI acceleration, it is important to enable and enforce delegation of the required cryptographic mechanisms to the underlying Solaris PKCS#11 provider that facilitates the AES-NI acceleration support. Make sure to include the required AES mechanisms (ex. CKM_AES) in the Java SunPKCS11 provider configuration file that lists as part of enabledMechanisms list or removes the mechanisms from the list of disabledMechanisms of the Java SunPKCS11 configuration file. Doing so forces the required AES operations performed by Intel AES-NI.
For SSL scenarios using AES for bulk encryption, it is important that the Java application server’s SSL configuration is enforced to use TLS_*_AES* cipher suites (-Dhttps.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA). For WS-Security scenarios using AES for XML Encryption scenarios, it is required to choose WS-SecurityPolicy using algorithm suite that includes AES ciphers. If the WS-SecurityPolicy specified algorithm suite is Basic256Rsa15, it uses Aes256 encryption and Rsa-oaep-mgf1p for key wrap. To enable acceleration, you need to remove the required bulk encryption algorithms in the disabledMechanisms list that forces those operations (ex. CKM_AES) performed by Intel AES-NI.
As I tested on a Xeon 5660 based server, using AES-NI for securing Java EE applications and XML Web services on Solaris 10 Update 9 showed significant SSL and WS-Security performance gains on Solaris 10. The SSL performance (RSA-1024/AES-256) showed 30% – 40% performance gain over not using AES-NI and WS-SecurityPolicy (using Basic256Rsa15) showed about 2X – 3X performance on XML encryption and decryption operations. Certainly Java security applications has strong advantage while running on Solaris on Intel Westmere processor based servers.
I am not a performance guru…but in my opinion Java Cryptographic performance on Linux (Intel Westmere) has NO EFFECT as Linux lacks support for a software PKCS#11 provider that takes advantage of AES-NI. If your Java applications has significant AES workloads then Solaris 10 is ideal choice on Intel Westmere based servers.
Try it out and let me know your comments.
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.
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 !
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.
I admit that I am not a SOA expert or pretend to be one ! Lately, I had a chance to explore few security features intended for securing XML Web Services and Java EE applications. With my little knowledge to SOA, I found that XML Web services play a vital role in SOA to enable loosely-coupled services and ensuring interoperability. From a security perspective, the core foundation of securing SOA solutions builds on XML Web Services Security standards and the underlying Java platform (unless you are using Microsoft .NET) . Last two weeks, Chad Prucha and I were test-driving SOA applications using Oracle Weblogic and Oracle Fusion Middleware on a Sun CMT server (T5440) particularly test driving SSL and WS-Security scenarios using WS-Policy/WS-SecurityPolicy standards. Our primary aim was to take advantage of On-chip Cryptographic acceleration provided by the UltraSPARC T2 processors of the T5440 server supporting the cryptographic mechanisms/cipher suites used by SSL and WS-SecurityPolicy. Believe it or not, it worked as piece of cake…. and the performance numbers were stunningly amazing. The Sun CMT servers (using its on-chip crypto accelerators) cruised on SSL and WS-Security with its cryptographic performance….RSA, AES, SHA2…too long to list here. If you consider yourself as a SOA enthusiast and have these following questions – Why should we care about Wire-speed Cryptographic acceleration for SOA or J2EE or XML Web Services performance ? Why it should even be considered in first place ? Is there is any security benefits ? If you do have those questions, then you may find this blog entry helpful otherwise please ignore.
Cryptographic operations plays a critical role in securing SOA application components particularly Java EE (formerly J2EE) applications and XML Web services supporting their transport-layer security (SSL) and message-layer security (WS-Security including XML Encryption, XML Digital Signature, WS-Policy, WS-SecurityPolicy) requirements. Adopting to cryptographic techniques helps IT organizations securing critical application infrastructures and adhere to industry-specific regulatory compliance mandates such as PCI DSS, HIPAA, FISMA and so forth.
But using Crypto for accomplishing SOA Message-level and Transport-level security induces significant performance degradation and taxes your CPU, Memory and Network bandwidth. SOA security experts often resort to using dedicated XML security appliances for delegating CPU intensive cryptographic operations such as Public-key cryptography (ex.RSA, DSA) based encryption and digital-signature, Symmetric-key based encryption (ex. AES, 3DES) to dedicated hardware-based accelarators – Which helps freeing up the main CPU resources and resulting significant performance gains in overall application throughput. In simpler terms, cryptographic accelerators and HSMs allows offloading computationally expensive cryptographic functions to dedicated hardware that supports cryptographic algorithms and handle cryptographic operations. Under the hood, the cryptographic functions are usually pushed through PKCS#11 standard interfaces using Solaris Cryptographic Framework (On Solaris) and OpenCryptoki (On Linux), or CryptoAPI framework (CAPI/CNG) in the case of Microsoft Windows environment. As a result, cryptographic accelerators proven to demonstrate significant gains in SOA application throughput and scalability by reducing the known CPU bottlenecks and related latency issues caused by cryptographic operations.
Over the past year I have become a big fan of Sun CMT Servers — and more specifically its Cryptographic capabilities, which makes it very compelling for delivering ultra-fast security for security sensitive SOA and Java EE applications.
Sun CMT servers are (Based On UltraSPARC T1/T2/T2Plus processors) based on Chip Multithreading Technology – CMT, which introduced on-chip cryptographic acceleration support through a dedicated cryptographic accelerator implemented on each core of the chip (8 Crypto Accelerators/Chip) – referred to as “Niagara Crypto Provider” (NCP). The introductory UltraSPARC T1 processor included a NCP implementation that facilitated public-key cryptographic mechanisms including RSA and DSA algorithms. The latest UltraSPARC T2 and T2+ processors extended more algorithms support by introducing symmetric-key based encryption/decryption mechanisms such as DES, 3DES, AES-128, AES-192, AES-256, RC4, Hashing operations such as MD5, SHA1, SHA256 and support for ECC algorithms (ECCp-160 and ECCb-163). In addition, the UltraSPARC T2 processors provides an on-chip Random Number Generator (N2RNG) to support random number generation operations intended for cryptographic applications. In practice, NCP makes use of Solaris Cryptographic Framework (SCF) for allowing user-level applications to offload their cryptographic operations and in effect the user applications can take advantage of NCP based on-chip cryptographic acceleration.
You had the gist of the story…now I am rushing out to catch the plane to Boston in an hour…… ! Yes, last three days I was attending Oracle Open World and co-presented with Chad on topic ”Wire Speed Cryptography for SOA and Java EE applications” - In our presentation, we put together all the concepts and tried our best to illustrate the applied crypto mechanisms related to SOA security and the secret sauce configuration/deployment of Sun CMT based cryptographic acceleration for delivering wire-speed security performance for SOA and Java EE applications. You may find the presentation is tailored to Oracle SOA and Weblogic but frankly speaking it applies well to all Java EE based SOA application deployments.
Enjoy the slides for now ! Feel free to ping for questions………all I can promise now… is sooner you will see a detailed Sun Blueprint on this topic ! So please stay tuned.
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:
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.
Certainly it is worth a try…and you should able to do it very quickly than configuring SSL for your web sever !
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
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
svcs - a | grep "kssl"
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 ! :-)
Are you tired of the high-level SPML content floating around the web from couple of analysts with no practical guidance ! If you are a practical guy..who want to explore SPML, here is something that you may find worth test-driving for SPML 1.0 amd SPML 2.0 based provisioning operations.
I had been using SPML using Sun IDM 7.0 for a while now. Most frequently, I forget the steps for configuration and also did’nt have the patience of going through the documentation (Frankly..I’m bit lazy). So, I ended up doing my crazy way and here is the cheat sheet of the steps required.
1. Make sure Sun IDM is deployed and tested to run in your Web container environment (My choice would be Glassfish on Solaris 10). Sorry, I am not a Windows guy
2. Open a terminal, set your JAVA_HOME and WSHOME environment variables
bash-3.00# export JAVA_HOME=export JAVA_HOME=/usr/java
bash-3.00# export WSHOME=/opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm
bash-3.00# export DISPLAY=<your host_name>:0.0
bash-3.00# cd /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/bin
bash-3.00# ./lh console
3. Configure SPML 1.0 and SPML 2.0 objects by importing them.
Configurator> import -f /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/sample/spml.xml
Configurator> import -f /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/sample/spml2.xml
Updated Configuration:User Extended Attributes
4. Set the Username/Password properties in Waveset.properties file.
bash-3.00# vi /opt/SUNWappserver/domains/domain1/applications/j2ee-modules/idm/config/Waveset.properties
Add the following to the end of Waveset.properties file:
4. Restart your Application Server:
bash-3.00# /opt/SUNWappserver/bin/asadmin stop-domain domain1
bash-3.00# /opt/SUNWappserver/bin/asadmin start-domain –user admin domain1
5. Test your SPML Web services connection. The following command will launch “SPML Monitor” Java application.
bash-3.00# ./lh spml
Here is my code for testing (both SPML 1.0 and SPML 2.0), just compile and run it.