This documentation is for WSO2 Identity Server 5.3.0 . View documentation for the latest release.

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. The Principal: This is typically the user who requires a service from tries to access a protected resource or service of a service provider entity.
  2. The Identity Provider: The SAML authority which provides the identity assertion to authenticate a principal An Identity Provider (IdP) is responsible for authenticating users and issuing assertions which include authentication/authorization decisions and user attributes.
  3. The Service Provider: The SAML consumer which provides service for principalsA Service Provider(SP) consumes the assertions issued by Identity Provider and provides services to the principals. 

The main use case scenario covered by SAML is the Principal (the user) requesting access to resource or service from the Service Provider. Then the Service Provider, using SAML, communicates with the Identity Provider to obtain identity assertion. The Service Provider makes the access control decision, depending on this assertion.


SAML 2.0 provides five main specifications:

This article provides more information about above specifications.

SAML 2.0 web browser-based SSO profile


If the user accesses a service at from a service provider:

  1. The service provider determines which identity provider to use (this is the case when there are multiple identity providers. SAML identity provider discovery profile may be used).
  2. The service provider generates a SAML message and then redirects the web browser to the identity provider along with the message.
  3. Identity provider authenticates the user.
  4. The identity provider generates a SAML message and then redirects the web browser back to the service provider.
  5. The service provider processes the SAML message and decides to grant or deny access to the user.


  1. Add the OpenSAML library to the build path of the project. You can download the open SAML JAR file from here.
  2. A sample <AuthnRequest> message can be found here.
  3. According to SAML 2.0 specifications, the message must contain an element. Create the Issuer element first.

    Code Block
    String issuerId = "saml2.sso.demo";
    IssuerBuilder issuerBuilder = new IssuerBuilder();
    Issuer issuer = issuerBuilder.buildObject("urn:oasis:names:tc:SAML:2.0:assertion", "Issuer", "samlp");
  4. Create the <AuthnRequest> next.

    Code Block
    // the issuerUrl is the url of the service provider who generates the  message
    String issuerUrl = "http://localhost:8080/saml2.sso.demo/consumer";
    DateTime issueInstant = new DateTime();
    AuthnRequestBuilder authnRequestBuilder = new AuthnRequestBuilder();
    AuthnRequest authnRequest = authnRequestBuilder.buildObject("urn:oasis:names:tc:SAML:2.0:protocol", "AuthnRequest", "samlp");

    The message may contain many other elements like , etc. those elements can be created and added to the message in the same way.

  5. Next encode the message.

    Code Block
    Marshaller marshaller = Configuration.getMarshallerFactory().getMarshaller(authnRequest);
    Element authDOM = marshaller.marshall(authnRequest);
    StringWriter rspWrt = new StringWriter();
    XMLHelper.writeNode(authDOM, rspWrt);
    String requestMessage = rspWrt.toString();
    Deflater deflater = new Deflater(Deflater.DEFLATED, true);
    ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
    DeflaterOutputStream deflaterOutputStream = new DeflaterOutputStream(byteArrayOutputStream, deflater);
    /* Encoding the compressed message */
    String encodedRequestMessage = Base64.encodeBytes(byteArrayOutputStream.toByteArray(), Base64.DONT_BREAK_LINES);
    String encodedAuthnRequest = URLEncoder.encode(encodedRequestMessage,"UTF-8").trim();
  6. Construct the redirection URL.


    redirectionUrl = identitypProviderUrl+ "?SAMLRequest=" + encodedRequestMessage;

  7. Redirect the user to the identity provider.



<Response> Message

The Identity provider must use HTTP POST or artifact binding to transfer the <SAMLResponse> message to the service provider. To read the <Response> message issued by the WSO2 Identity Server, do the following:

  1. A sample <Response> message can be found here.
  2. The response message must be fetched from the request.


    responseMessage = request.getParameter("SAMLResponse").toString(); 

  3. The fetched “responseMessage” is unmarshaled and the SAML message is retrieved.

    Code Block
    DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
    DocumentBuilder docBuilder = documentBuilderFactory.newDocumentBuilder();
    byte[] base64DecodedResponse = Base64.decode(responseMessage);
    ByteArrayInputStream is = new ByteArrayInputStream(base64DecodedResponse);
    Document document = docBuilder.parse(is);
    Element element = document.getDocumentElement();
    UnmarshallerFactory unmarshallerFactory = Configuration.getUnmarshallerFactory();
    Unmarshaller unmarshaller = unmarshallerFactory.getUnmarshaller(element);
    Response response = (Response) unmarshaller.unmarshall(element);
  4. The retrieved SAML 2.0 Response message can be easily processed. For example, lets takes the User Name or the Subject's Name Id.


    String subject = response.getAssertions().get(0).getSubject() .getNameID().getValue();

  5. Alternatively, if the response is signed by the IdP, you can retrieve the certificate.


    String certificate = response.getSignature().getKeyInfo().getX509Datas().get(0).getX509Certificates().get(0).getValue();



Identity-agent-sso is an implementation of all the details discussed above, which can be used to implement SSO enabled web applications. Travelocity is a sample SSO enabled web-app, which is implemented based on Identity-agent-sso.

Relay state

The RelayState parameter is used so that the service provider can pass some value to the identity provider with the AuthnRequest and get the same value back with the Response. This value can be any string and can be useful for service provider application logic (when there is a failure, redirecting to the URL that comes as the RelayState parameter is one way that this can be used).

  • For a inbound request to the Identity Server, if the RelayState parameter is present, the Identity Server sends back the same value in the response.
  • For federation using SAML2, the Identity Server uses the RelayState parameter to pass the session index, which is required to continue the authentication flow after receiving authentication response.

Identity provider initiated SSO

To initiate IdP Initiated SSO you need to perform a HTTP GET/POST to the following URL (assume the registered service provider issuer ID is


This request will authenticate and redirect the user to the registered Assertion Consumer URL. Optionally, you can send in a RelayState parameter an 'acs' parameter as follows.



This request will authenticate and redirect the user to the URL in the RelayState 'acs' parameter itself.


Either you could have SP Initiated SSO only, or SP Initiated SSO and IdP Initiated SSO. You can't have IdP initiated SSO only. By design, SP Initiated SSO is more restrictive and secure. If a service provider is allowed to do IdP Initiated SSO, it would automatically imply that this service provider is allowed to do SP initiated SSO as well.