Friday, October 24, 2014

WSO2 Identity Server / Thinktecture - Identity Broker Interop

Today is the third and the final day of  the interop event happening right now in Virginia Beach, USA. Today we were able to successfully interop test a selected set of Identity Broker patterns with Thinktecture Identity Provider.

In the first scenario, a .NET web application deployed in IIS talks to Thinktecture via WS-Federation. Thinktecture is acting as the broker and asks the user to pick the Identity Provider. Then Thinktecture will redirect the user to the WSO2 IS via WS-Federation.


In the second scenario, WSO2 IS is acting as the broker. Salesforce which acts as the service provider talks to WSO2 IS via SAML 2.0. WSO2 IS asks the user to pick the Identity Provider. Then WSO2 IS will redirect the user to the Thinktecture via WS-Federation. In the return path WSO2 IS will convert the WS-Federation response into a SAML 2.0 response and sends it back to the Salesforce.


Thursday, October 23, 2014

AMAZON Still Uses OpenID!

Few have noticed that Amazon still uses (at the time of this writing) OpenID for user authentication. Check it out yourself: go to www.amazon.com, and click the Sign In button. Then observe the browser address bar. You see something similar to the following, which is an OpenID authentication request:

https://www.amazon.com/ap/signin?_encoding=UTF8&
openid.assoc_handle=usflex&
openid.claimed_id= http://specs.openid.net/auth/2.0/identifier_select&
openid.identity= http://specs.openid.net/auth/2.0/identifier_select&
openid.mode=checkid_setup&
openid.ns=http://specs.openid.net/auth/2.0&
openid.ns.pape= http://specs.openid.net/extensions/pape/1.0&
openid.pape.max_auth_age=0&
openid.return_to= https://www.amazon.com/gp/yourstore/home

WSO2 Identity Server / Microsoft ADFS - Identity Broker Interop

We are in the middle of an interop event happening right now in Virginia Beach, USA. Today and yesterday we were able to successfully interop test a selected set of Identity Broker patterns with Microsoft ADFS 2.0/3.0.

In the first scenario, a .NET web application deployed in IIS talks to ADFS via WS-Federation. ADFS is acting as the broker and asks the user to pick the Identity Provider. Then ASFS will redirect the user to the WSO2 IS via WS-Federation.


In the second scenario, a .NET web application deployed in IIS talks to ADFS via SAML 2.0. ADFS is acting as the broker and it asks the user to pick the Identity Provider. Then ADFS will redirect the user to the WSO2 IS via SAML 2.0.


In the third scenario, WSO2 IS is acting as the broker. Salesforce which acts as the service provider talks to WSO2 IS via SAML 2.0. WSO2 IS asks the user to pick the Identity Provider. Then WSO2 IS will redirect the user to the ADFS via WS-Federation. In the return path WSO2 IS will convert the WS-Federation response into a SAML 2.0 response and sends it back to the Salesforce.


Saturday, October 18, 2014

POODLE Attack and Disabling SSL V3 in WSO2 Carbon 4.2.0 Based Products

Early this week Google researchers announced that they have found a bug in the SSL 3.0 protocol. The exploit could be used to intercept critical data that’s supposed to be encrypted between clients and servers.

The exploit first allows attackers to initiate a “downgrade dance” that tells the client that the server doesn’t support the more secure TLS (Transport Layer Security) protocol and forces it to connect via SSL 3.0.

From there a man-in-the-middle attack can decrypt secure HTTP cookies.

POODLE

Google calls this the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack.

This means, even both your server and the client support TLS, still due to the downgrade attack, both the parties can be forced to use SSL 3.0. If any one of the party disables its support for SSL 3.0 - that will help to mitigate the attack.

Both Chrome and Firefox already announced that they are going to disable the SSL 3.0 support by default. Firefox 34, with SSL 3.0 disabled,  will be released on 25th November. If you want to disable SSL 3.0 on firefox now, you can use the plugin SSL Version Control.

Chrome has already issued a patch to disable SSL 3.0.

Disable SSL V3 on WSO2 Carbon 4.2.0

Following explains how to disable SSL 3.0 support on WSO2 Carbon 4.2.0 based servers
  1. Open [product_home]/repository/conf/catalina-server.xml
  2. Find the Connector configuration corresponding to TLS - usually this is having the port as 9443 and sslProtocol as TLS.
  3. If you are using JDK 1.6 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with:  sslEnabledProtocols="TLSv1"
  4.  If you are using JDK 1.7 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with:  sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
If you have enabled pass-thru transport in any WSO2 product (ESB, API Manager) - you also need to do the following configuration change.
  1. Open [product_home]/repository/conf/axis2/axis2.xml
  2. Find the transportReceiver configuration element for org.apache.synapse.transport.passthru.PassThroughHttpSSLListener
  3. If you are using JDK 1.6 - add the following parameter under transportReceiver.
  4.  <parameter name="HttpsProtocols">TLSv1</parameter> 
  5. If you are using JDK 1.7 - add the following parameter under transportReceiver.
  6.  <parameter name="HttpsProtocols">TLSv1,TLSv1.1,TLSv1.2</parameter> 
Following explains how to validate the fix. You can download TestSSLServer.jar from here.

$ java -jar TestSSLServer.jar localhost 9443 

To test the pass-thru transport use the following command with the corresponding port.

$ java -jar TestSSLServer.jar localhost 8243 

Output before the fix

Supported versions: SSLv3 TLSv1.0
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
  SSLv3
     RSA_EXPORT_WITH_RC4_40_MD5
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_EXPORT_WITH_DES40_CBC_SHA
     RSA_WITH_DES_CBC_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
     DHE_RSA_WITH_DES_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_256_CBC_SHA
     DHE_RSA_WITH_AES_256_CBC_SHA
  (TLSv1.0: idem)


Output after the fix

Supported versions: TLSv1.0
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
  TLSv1.0
     RSA_EXPORT_WITH_RC4_40_MD5
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_EXPORT_WITH_DES40_CBC_SHA
     RSA_WITH_DES_CBC_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
     DHE_RSA_WITH_DES_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_256_CBC_SHA
     DHE_RSA_WITH_AES_256_CBC_SHA