SSO With The WSO2 Identity Server

A Walk Through SSO

Sso walk-through from Suresh Attanayake

Apache Solr with Curl

Apache Solr is an indexing server which helps to index your applications data for fast searches. For example, when you upload a file to your FTP server, you add some meta data of the file such as id, name, type, owner, path etc to the Apache Solr server. Then Solr will index your files based on the provided meta data. The set of metadata of the files your wish to use for indexing should be defined as fields in the schema.xml of the Solr server. The basic attributs : id, name, subject and version are defined by default in the schema.xml along with some other attributes. The id attribute is defined as a MUST attribute. In Solr jargon, a Document is a collection of such attributes.

In my previous post I explained the steps to install Solr in the WSO2 Application server. In this post I will be explaining how to use Curl to add documents and to query using the Apache Lucene query language. 

Adding a document,

To add, delete or to update a document the "update" target of the Solr should be used. 

curl http://127.0.0.1:9763/solr/update/?commit=true -H "Content-Type: text/xml" --data-binary '<add><doc><field name="id">0000</field><field name="name">DocmentOne</field><field name="subject">Apache Solr</field></doc></add>';

The response is given bellow

Now lets add another document,

curl http://127.0.0.1:9763/solr/update/?commit=true -H "Content-Type: text/xml" --data-binary '<add><doc><field name="id">0001</field><field name="name">DocumentTwo</field><field name="subject">Apache Lucene</field></doc></add>';

Now lets search for documents. Following command will read all documents,

curl http://127.0.0.1:9763/solr/select?q=*:*

The response is given bellow,

Search by id,

curl http://127.0.0.1:9763/solr/select?q=id:0000

response is given bellow,

Search for document with "Doc" string in it's name,

curl http://127.0.0.1:9763/solr/select?q=name:Doc*

The response is given bellow,

Now lets delete a update a field. Lets change the subject of the Document Two,

curl http://127.0.0.1:9763/solr/update/?commit=true -H "Content-Type: text/xml" --data-binary '<add><doc><field name="id">0001</field><field name="name">DocumentTwo</field><field name="subject">New Apache Lucene</field></doc></add>';

Now lets delete a document,

curl http://127.0.0.1:9763/solr/update/?commit=true -H "Content-Type: text/xml" --data-binary '<delete><id>0001</id></delete>';

Here are some  useful links on Solr:

• http://wiki.apache.org/solr/UpdateXmlMessages
• http://www.solrtutorial.com/solr-query-syntax.html
• http://lucene.apache.org/solr/4_1_0/tutorial.html

OpenID Connect Basic Client Profile with WSO2 Identity Server 4.1.1

OpenID Connect is an identity framework build on OAuth 2.0 which utilize and extend OAuth 2.0 messages and code flows etc. The WSO2 Identity Server implements the OpenID Connect Basic Client Profile from the servers version 4.1.0 onward. This blog post provides steps for a short demonstration of the feature.

As for OAuth 2.0, first the client application needs to be registered. Please follow this blog post and register the OAuth 2.0 play ground application.

The OpenID Connect Basic Client Profile utilizes the OAuth 2.0 Authorization Code flow. So the second step is to get an authorization code with the scope "openid". Use the OAuth 2.0 play ground application to get the authorization code, make sure to use the scope openid. Other than the flow of OAuth 2.0 to get the the Authorization Code, in OpenID Connect the user is prompted for the consent before the token issued to the client.

Third step is to get the access token using the authorization code. Use the playground application to get the access token. Since this authorization code is issued for the scope openid, the ID Token will be returned along with the access token.

Final step is to access the userinfo endpoint with the received access token. As per the specification the recieved bearer token should be sent using the HTTP Authorization header. The curl command is,

curl -k -H "Authorization: Bearer 4164157d677a6cd3a22e26e24c30135d" https://localhost:9443/oauth2endpoints/userinfo?schema=openid

As the response The WSO2 Identity Server returns a JWT with user claims.

{"sub":"PRIMARY\/sureshatt","email":"sureshgemunu@mymail.com","name":"Suresh Attanayake","family_name":"Attanayake","preferred_username":"sureshgemunu","given_name":"Suresh"}

Installing Solr 4.1.0 In WSO2 Application Server 5.0.1

• Download the solr-4.1.0.zip from here.
• Extract the downloaded solr-4.1.0.zip locally. 
• Locate the "solr" folder inside the extracted solr-4.1.0 in the path solr-4.1.0/example/solr
• Move the "solr" folder to a location you want to use as SOLR HOME. For example /home/wso2/solrhome/solr. So now the SOLR HOME is "/home/wso2/solrhome/solr".  
• Download WSO2 AS from here. 
• Extract wso2as-5.0.1.zip.
• Locate the "wso2server.sh" file in the extracted wso2as-5.0.1 in the path wso2as-5.0.1/bin/wso2server.sh. (In Windows it should be wso2server.bat)
• Open the wso2server.sh file from a text editor and locate Java system property configurations at the very bottom. 
• Add the following parameter to set the SOLR HOME. Use the same location we used above.
  -Dsolr.solr.home="/home/wso2/solrhome/solr" \
• So the final configuration should look, 

  while [ "$status" = "$START_EXIT_STATUS" ]
  do
      $JAVACMD \
      -Xbootclasspath/a:"$CARBON_XBOOTCLASSPATH" \
      -Xms256m -Xmx1024m -XX:MaxPermSize=256m \
      -XX:+HeapDumpOnOutOfMemoryError \
      -XX:HeapDumpPath="$CARBON_HOME/repository/logs/heap-dump.hprof" \
      $JAVA_OPTS \
      -Dcom.sun.management.jmxremote \
      -classpath "$CARBON_CLASSPATH" \
      -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" \
      -Djava.io.tmpdir="$CARBON_HOME/tmp" \
      -Dcatalina.base="$CARBON_HOME/lib/tomcat" \
      -Dwso2.server.standalone=true \
      -Dcarbon.registry.root=/ \
      -Djava.command="$JAVACMD" \
      -Dsolr.solr.home="/home/wso2/solrhome/solr" \
      -Dcarbon.home="$CARBON_HOME" \
      -Djava.util.logging.config.file="$CARBON_HOME/repository/conf/log4j.properties" \
      -Dcarbon.config.dir.path="$CARBON_HOME/repository/conf" \
      -Dcomponents.repo="$CARBON_HOME/repository/components/plugins" \
      -Dconf.location="$CARBON_HOME/repository/conf"\
      -Dcom.atomikos.icatch.file="$CARBON_HOME/lib/transactions.properties" \
      -Dcom.atomikos.icatch.hide_init_file_path=true \
      -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true \
      -Dcom.sun.jndi.ldap.connect.pool.authentication=simple  \
      -Dcom.sun.jndi.ldap.connect.pool.timeout=3000  \
      -Dorg.terracotta.quartz.skipUpdateCheck=true \
      -Djava.security.egd=file:/dev/./urandom \
      org.wso2.carbon.bootstrap.Bootstrap $*   
  done

• Now start the WSO2 Application server using the wso2server.sh script by issuing the command in a terminal,
  sh wso2server.sh
• When server is started, access the url https://172.30.3.15:9443/carbon/
• Login as username=admin, password=admin
• Go to Main -- Manage -- Applications -- Add -- Web Applications

• Now we are going to add Solr as a web application to the Application Server. Locate the solr-4.1.0.war file in the path solr-4.1.0/dist/solr-4.1.0.war of the extracted solr-4.1.0.zip.
• Before uploading Solr to the application server, rename solr-4.1.0.war to solr.war.
• In the WSO2 Application Server console, click on choose file, locate and choose the solr.war and then upload. 

• Solr will be deployed in WSO2 AS in few seconds.
• Click on "Go To URL" to visit Solr admin panel

Exporting The Private Key Of A JKS As A PEM File

This is indeed a frequent use case  but the Java Keytool doesn't provide an easy way to get this done. I came across this requirement when I was configuring the Apache2 as a proxy to balance the load between WSO2 Identity Server nodes.

Lets say you have a JKS type keystore (say wso2carbon.jks) with your private key in it.

Step 1 : Convert the JKS into to a P12

keytool -importkeystore -srckeystore wso2carbon.jks -destkeystore server.p12 -srcstoretype jks -deststoretype pkcs12

Step 2 : Export the Private Key as a PEM file

openssl pkcs12 -in server.p12 -out server.pem

The server.pem file is the Private Key certificate exported.

Step 3 : Exporting the Certificate

openssl x509 -outform der -in server.pem -out server.crt

The server.crt file is the Public Key certificate exported.


Now you can use these two files when configuring Apache2 as,

SSLCertificateFile /path/to/server.crt
SSLCertificateKeyFile /path/to/server.pem

XACML + Kerberos For Secure Proxy Services

Configuring Kerberos Authentication

1. Click on the bellow icon of the proxy service you need to secure with Kerberos.

2. Select Yes from the dropdown. 

3. Select scenario 16 "Kerberos Authentication" and click Next. 

4. Provide the Service Principle and password and click Finish. 

Configuring XACML mediator 

1. Click on Design View icon of the proxy service. 

2. Click Next on the first page. 

3. Select Define Inline and click on Create. 

4. Click on Entitlement

5. Scroll down and do the configurations. Provide the entitlement service URL and a valid users credentials in the entitlement server. 

Once done, click on "Save & Close" and click Next and in the next page click on Finish. 

6. Now click on the "Source View" of the proxy service.

7. Now locate the <entitlementService> element and put the following configuration. 

callbackClass="org.wso2.carbon.identity.entitlement.mediator.callback.KerberosEntitlementCallbackHandler"

This configuration is required for the mediator to pic the client principle name from the Kerberos token. 

Once you are done save and close. 

Now we are done with configuring the ESB for XACML based authorization. Now the ESB will contact the WSO2 Identity Server to take Authorization decisions for every request. Now we need to define XACML policies at the WSO2 Identity Server. 

1. Start the WSO2 Identity Server with a port offset 1. So the Identity Server will start in the port 9444. 

2. Login to the WSO2 Identity Server.

3. Click on Administration 

4. Click on Add New Entitlement Policy 

5. Provide a policy name 

6. This policy is applied for the resource. In this case the resource is the proxy service. 

7. Lets create Rules. We create a rule such that only the users with the Role "admin" can "read" the service. Click on the green icon to the right add another rule. 

8. Lets add another rule such that nobody else can do any operation on the resource. 

9. Once done click on Finish.

10. Now lets deploy this policy. Click on Sync With PDP

Now we have done with configuring policies at the WSO2 Identity Server. 

After following all these steps you have secured the proxy service with Kerberos and XACML. 

  

How To Expose WSO2 Server APIs In HTTP

By default WSO2 Server APIs (called AdminServices) are exposed in HTTPS only. This is to provide confidentiality to the messages exchanged between the APIs and clients. Using HTTPS is a MUST if these messages are routing through public channels, otherwise an attacker could sniff the traffic and get the confidential information such as credentials.

However, in some scenarios WSO2 Servers are hosted behind a firewall and all these communications happens inside a security zone. In such a situation we can assume all channels are secured and hence we should not worry about the message confidentiality. In fact, enforcing HTTS in such a deployment only introduces extra unnecessary burdens such as key management, certificate distribution etc. Further HTTPS will definitely decrease the system's overall performance as well.

Therefor sometimes it is important to expose WSO2 Server APIs in HTTP as well. This feature will be available in WSO2 patch release version 4.0.5 onward, that is this feature would be available in the WSO2 Identity Server 4.0.1 onward.

How to configure

<HttpAdminServices></HttpAdminServices>

Where to find the configuration 

• Locate the carbon.xml file in the path <carbon-home>/repository/conf/carbon.xml
• Locate the Axis2Config element
• Locate the commented out above configuration in Axis2Config element
• Make sure to un-comment the configuration before use  

What are the valid inputs

• Using the wildcard * will expose all AdminServices in HTTP.
• Using comma separated AdminServices names will expose only those AdminServices in HTTP 

How to make sure now they are exposed in HTTP 

• Start the WSO2 server with the -DosgiConsole switch. (sh wso2server.sh -DosgiConsole)
• Once the server is started, use the bellow command to list all AdminServices and their End Point URLs (EPR)

listAdminServices

Examples

1). <HttpAdminServices>*</HttpAdminServices>
2). <HttpAdminServices>UserAdmin,OAuth2TokenValidationService,KeyStoreAdminService</HttpAdminServices>

Getting User Claims Over The SAML SSO Token

Many SSO webapps require claims of the authenticated users such as the email, date of birth, language, country etc. In this blog post I will be guiding on how to get authenticated users claims over the SAML SSO Response token.

I believe you already know how to register a SAML SSO Service Providers at the WSO2 Identity Server and how to get the SSO authentication done (If not please refer to my previous post or this article).

When you register your Service Provider select the Enable Attribute Profile option.

Now you can start adding claims. Select the required claim from the drop down and click on Add Claim button to add the required claim. Keep on adding required claims. (Note : User Roles in the Identity Server are available as a claim)

Once you are done with adding claims, click on Add button to register the service provider.

After the Service Provider is being registered, the Identity Server will generate a random number called the ConsumerIndex for the Service Provider.

The ConsumerIndex is analogous to the AttributeConsuminServiceIndex defined in the SAML 2.0 specifications. This generated ConsumerIndex will be used by the Identity Server to map the Service Provider to the set of requested attribute. So when the Service Provider needs to get user attributes it should send this index number in the SAML 2.0 Authentication Request.

Given bellow is a sample AuthnRequest message with the AttributeConsuminServiceIndex,

Now the Identity Server will respond back with the required claims in the SAML 2.0 Response message. Claims are placed inside an <AttributeStatement> element. Each claim is wrapped inside an <Attribute> element Given bellow is a sample Response message with requested claims.

You can demonstrate this with the sample webapp given here. The source-code of the webapp can be checked out from here.

How To Read A SAML 2.0 Response With OpenSAML

This blog post provides step by step to read a SAML Response message sent by the Identity Provider in a SAML 2.0 Single Sign On environment. I'm using the Java OpenSAML 2.2.3 library.


Fetching the SAML Response message from the HttpServletRequest

According to the SAML 2.0 Bindings specification, the Identity Provider MUST send the SAML Response with the parameter name "SAMLResponse".

String responseMessage = httpServletRequest.getParameter("SAMLResponse");

Unmarshalling the response

First we need to create a DOM Element object out of the response string.

ByteArrayInputStream is = new ByteArrayInputStream(responseMessage.getBytes());

DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
documentBuilderFactory.setNamespaceAware(true);
DocumentBuilder docBuilder = documentBuilderFactory.newDocumentBuilder();

Document document = docBuilder.parse(is);
Element element = document.getDocumentElement();

Now lets unmarshall the element.

UnmarshallerFactory unmarshallerFactory = Configuration.getUnmarshallerFactory();
Unmarshaller unmarshaller = unmarshallerFactory.getUnmarshaller(element);
XMLObject responseXmlObj = unmarshaller.unmarshall(element);

Casting the response to the SAML 2.0 Response message.

Response response = (Response) responseXmlObj;

Now we have the SAML 2.0 Response message. Given bellow is a sample Response message.

Processing the Response message

Lets process the above Response message.

Reading the Assertion. This Response has only one Assertion

Assertion assertion = response.getAssertions().get(0);

Reading the Subject name (Subject is what was authenticated at the IDP)

String subject = assertion.getSubject().getNameID().getValue();

Reading the issuer (Issuer is the IDP who issued the Response object)

String issuer = assertion.getIssuer().getValue();

Reading the audience (To whom the Response was issued)

String audience = assertion.getConditions().getAudienceRestrictions().get(0).getAudiences().get(0).getAudienceURI();

You can read other parts of the Response message other than the Assertion. Reading the status

String statusCode = response.getStatus().getStatusCode().getValue();

Reading the signature

Signature sig = response.getSignature();

Validating the signature

SignatureValidator validator = new SignatureValidator(credential);
validator.validate(sig);

Likewise you can process the entire Response message using the OpenSAML library.