WSO2 Identity Server - Extension Points - Part 1 - SAML

This is the first post of a series of post to come, to serve as a catalog of extension points available within WSO2 Identity Server as of IS 5.1.0 version which is to be released soon. Most of them are available in 5.0.0 version as well. We have quite a lot of flexibility provided for the users to shape Identity Server to serve exactly what they require via these extension points.

There are 2 types of extensions available in WSO2 Identity Server as of now. Most of these require a restart of the server in order to be effective, but can be configured dynamically without a restart of the server. Few of the extensions like UI theming can be made without a server restart.
  • Drop the extension developed as an OSGI bundle, followed by a server restart,  configure it dynamically
      • eg: custom user store managers
  • Drop the extension developed as a Java component, configure in a configuration file, then restart the server. Configure it dynamically via the UI.
      • eg: custom authenticators


Files Used for Configurations

  1. The configuration files for these extensions are located at <IS_HOME>/repository/conf folder. 
  2. Most of the configurations specific to identity server resides identity/identity.xml within this folder. 
  3. Configurations relevant to federation scenarios(authentication framework) resides at identity/application-authentication.xml file. 
  4. Identity management related configurations resides at identity/identity-mgt.properties file. 
  5. Entitlement(XACML) related configurations resides at identity/entitlement.properties file.
      
    Apart from above we have multiple listeners and UI modifications allowed for branding purposes.
Note: Though the extension points are available to cater for variety of enterprise needs, this introduces a maintenance overhead in long term. If these are valid generic scenarios we will be merging these to product itself, otherwise these extensions needs to be maintained at major upgrades if there is any API change or improvements done at interfaces.

First our attention is for SAML based scenario as that is a widely used standard on Single Sign On.

Please find a list of available extension points related to this scenario below.

All the implementation using following extension point needs to be configured at <IS_HOME>/repository/conf/identity/identity.xml file under the element ‘SSOService’.

  1. Custom SSO Signer

Usage:

When we want to change the way we sign/validate the SAML Response or Assertion. If this is just changing the algorithms default UI configurations are available without going for this extension.

Sample:



Interface:

org.wso2.carbon.identity.sso.saml.builders.signature.SSOSigner

Default Implementation:

org.wso2.carbon.identity.sso.saml.builders.signature.DefaultSSOSigner

  1. Custom SSO encryption

Usage:

When we want to change the way we encrypt the SAML assertion in local

Interface:

org.wso2.carbon.identity.sso.saml.builders.encryption.SSOEncrypter

Default Implementation:

org.wso2.carbon.identity.sso.saml.builders.encryption.DefaultSSOEncrypter

  1. SAMLAssertionBuilder

Usage:

This extension point can control how the SAML assertion it built. Intend use of the extension point is put the given inputs in the SAML assertion format as preferred. This extension point gives full control over what is there in SAML assertion.  

Interface:

org.wso2.carbon.identity.sso.saml.builders.assertion.SAMLAssertionBuilder

Default Implementation:

org.wso2.carbon.identity.sso.saml.builders.assertion.DefaultSAMLAssertionBuilder

  1. SAML2HTTPRedirectSignatureValidator


Usage:

Can be used to differentiate(deflating, encoding etc.) on how the signature is validated at SAML HTTP redirect binding.

Interface:

org.wso2.carbon.identity.sso.saml.validators.SAML2HTTPRedirectSignatureValidator

Default Implementation:

org.wso2.carbon.identity.sso.saml.validators.SAML2HTTPRedirectDeflateSignatureValidator

  1. ResponseBuilder

Usage:

This extension point provides the full control over the SAML Responses built to sent over to replyingparties

Interface:

org.wso2.carbon.identity.sso.saml.builders.ResponseBuilder

Default Implementation:

org.wso2.carbon.identity.sso.saml.builders.DefaultResponseBuilder
org.wso2.carbon.identity.sso.saml.builders.ErrorResponseBuilder



 If there are any other use cases or samples you have found useful around WSO2 Identity Server SAML implementation, you are most welcome to add them here, for the benefit of all. Thanks!

The second post is available at OAuth - Extension Points Part 2 - WSO2 Identity Server on the extension points in WSO2 Identity Server related to OAuth2.0.


Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

Image
Digital signing is a widely used mechanism to make digital contents authentic. By producing a digital signature for some content, we can let another party capable of validating that content. It can provide a guarantee that, is not altered after we signed it, with this validation. With this sample I am to share how to generate the a signature for SOAP envelope. But of course this is valid for any other content signing as well. Here, I will sign The SOAP envelope itself An attachment  Place the signature inside SOAP header  With the placement of signature inside the SOAP header which is also signed by the signature, this becomes a demonstration of enveloped signature. I am using Apache Santuario library for signing. Following is the code segment I used. I have shared the complete sample here to to be downloaded . public static void main(String unused[]) throws Exception {         String keystoreType = "JKS";         String keystoreFile = "src/main/resour
Read more

How to convert WSDL to Java

Image
Background Basically WSDL (Web Services Development Language) is an XML document used to describe or locate web services. WSDL stands for Web Services Description Language. The document describes a Web service. It specifies the location of the service and the operations that can be taken.  WSDL2Java is distributed with Axis2 package of Apache and need to set-up Axis2 to use this service. A  guide to set-up Axis2  can be found in apache organization documents .WSDL 2.0 is the currently using version. Obviously JDK should be properly installed too. Note: For the 3rd method you are not needed to set these things by yourself. The WSDL document includes server Java programs for Web services and generated classes using WSDL2Java feature includes client stubs, server skeletons and data types that can help in writing client side. The generated stub classes play a great role in distributed computing and if you are interested can read on  what are stub classes . In brief talking, 
Read more

How to Write a Custom User Store Manager - WSO2 Identity Server 4.5.0

Image
With this post I will be demonstrating writing a simple custom user store manager for WSO2 Carbon and specifically in WSO2 Identity Server 4.5.0 which is released recently. The Content is as follows, Use case Writing the custom User Store Manager Configuration in Identity Server You can download the sample here. Use Case By default WSO2 Carbon has four implementations of User Store Managers as follows. org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager org.wso2.carbon.user.core.ldap.ActiveDirectoryLDAPUserStoreManager Let's look at a scenario where a company has a simple user store where they have kept customer_id, customer_name and the password (For the moment let's not worry about salting etc. as purpose is to demonstrate getting a custom user store into action). So the company may want to keep this as it is, as there may be other serv
Read more