WSO2 Identity Server - Supporting Binary Claims such as Windows SID and objectGUID

Configuring a binary attribute (such as Windows SID or objectGUID) as a claim in WSO2 Identity Server and sending it over XML token such as SAML needs an additional configuration.

Problem Identification

 [2016-03-17 16:48:48,203] @nextlabs.com [1] [IS]ERROR {org.wso2.carbon.identity.sso.saml.processors.SPInitSSOAuthnRequestProcessor} - Error processing the authentication request  
 org.wso2.carbon.identity.base.IdentityException: Error Serializing the SAML Response  
     at org.wso2.carbon.identity.base.IdentityException.error(IdentityException.java:162)  
     at org.wso2.carbon.identity.sso.saml.util.SAMLSSOUtil.marshall(SAMLSSOUtil.java:352)  
     at org.wso2.carbon.identity.sso.saml.processors.SPInitSSOAuthnRequestProcessor.process(SPInitSSOAuthnRequestProcessor.java:161)  
     at org.wso2.carbon.identity.sso.saml.SAMLSSOService.authenticate(SAMLSSOService.java:164)  
     at org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet.handleAuthenticationReponseFromFramework(SAMLSSOProviderServlet.java:691)  
 .....  
 .....  
 .....  
 Caused by: org.w3c.dom.ls.LSException: The character '☼' is an invalid XML character  
     at org.apache.xml.serialize.DOMSerializerImpl.write(Unknown Source)  
     at org.wso2.carbon.identity.sso.saml.util.SAMLSSOUtil.marshall(SAMLSSOUtil.java:348)  
     ... 55 more  
 Caused by: java.io.IOException: The character '☼' is an invalid XML character  
     at org.apache.xml.serialize.BaseMarkupSerializer.fatalError(Unknown Source)  
     at org.apache.xml.serialize.BaseMarkupSerializer.surrogates(Unknown Source)  

Solution

Add the following parameter in <carbon_home>/repository/conf/usermgt.xml for each binary attribute that you wish to convert to XML.

 <Property name="java.naming.ldap.attributes.binary">objectGUID</Property>  

Enterprise Identity Patterns with WSO2 IS: Complying to SOX with SaaS Applications

The Sarbanes-Oxley(SOX) act of 2002 is a legislation passed by the U.S. Congress to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise, as well as improve the accuracy of corporate disclosures[1]. The act require the identity and access management (IAM) program of an enterprise to meet the following to become compliant with the standards.

• Securely manage and assign and control user access rights
• Disseminate tasks and associated privileges among multiple users
• Adjust user access rights when responsibilities change
• Revoke user access upon termination
• Provide uniform access policy
• Manage access based on business roles
• Manage allocation of user credentials

In an enterprise, managing user credentials and access rights in a decentralized way to meet the above requirement is highly inefficient, costly, error prone and eventually will not meet the requirements. This is because today's enterprise has a large number of different systems commissioned over a time. The complexity becomes worse as some systems are cloud based SaaS applications while others are on-premise.

How do you establish a centralized IAM program to achieve the above requirements?

• Centrally manage credentials, access controls and profiles
• Connect all possible on-premise systems the centrally managed IAM system
• Provision users, profiles and access control to cloud and external domains
• Use single sign on protocols to validate credentials at central point and provide a token to authenticate to on-premise and cloud system

WSO2 Identity server is a central backbone that connects and manages multiple identities across applications, APIs, the cloud, mobile, and Internet of Things devices, regardless of the standards on which they are based built on. This is how one can use WSO2 Identity server to achieve the above requirements.

WSO2 IS connects to the enterprise LDAP, and the unified system meets above requirements. The principals of the design are,

• Configure WSO2 IS to maintain users and roles in the LDAP
• Design LDAP groups based on on business roles. Use required level of granularity provide segregation of duties. As users change business roles assign them roles at WSO2 IS admin console - the centralized IAM system
• Assign correct access controls to different business roles
• Configure SSO with on-premise and cloud services (SaaS and PaaS) based on SAML2, OpenID Connect and open standards
• For propagating access controls,
• Use SCIM or web APIs to provision/deprovision users into external system
• On-premise systems are in the same identity control domain. We can have a choice of provisioning, or providing roles along with the authentication toke, or LDAP synching.  Use one of the methods compatible with the system.
• Write connectors for automatic provisioning and de-provisioning of users

[1] https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act
[2] http://wso2.com/products/identity-server/

Configure SAML SSO to PeopleHR using WSO2 Identity Server

I wanted PeopleHR to do SAML SSO with WSO2 Identity provider, but couldn't find any documentation that gave generic steps on how to configure SAML SSO in PeopleHR. I hope this blog will help you through. I will try to keep it as generic as possible and use WSO2 Identity Server as an example only.

1 - Create a metafile in the following format

<?xml version="1.0"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="dimuthul.local">
  <IDPSSODescriptor xmlns:ds="http://www.w3.org/2000/09/xmldsig#" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>PEM-FORMAT-OF-THE-PUBLIC-KEY</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://localhost:9443/samlsso"/>
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://localhost:9443/samlsso"/>
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://localhost:9443/samlsso"/>
  </IDPSSODescriptor>
  <ContactPerson contactType="technical">
    <SurName>Support</SurName>
    <EmailAddress>support@dimuthu.com</EmailAddress>
  </ContactPerson>
</EntityDescriptor>

2 - Upload it to PeopleHR by Going to Settings-->Company

3 - Now at the SAML Provider side here are the parameters. These parameters are found by studying the AuthnRequest.

• EntityId/Issuer (relying party or service provider Id) is "test-app-peopleweb"
• ACS (Assertion Consumer) URL is https://{replace-with-your-domain-name}.peoplehr.net/Pages/Saml/Consume.aspx
• NameID format is urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
• Enable assertion signing 
• Supports IdP initiated SSO
• Supports SP initiated SSO

Important points to know,

• According to the SAML specification the EntityId given in the metadata.xml file and the "Issuer" of the SAML response should be equal. But in PeopleHR implementation it need not checked. 
• The Issuer in AuthnRequest must be "test-app-peopleweb" and it is not changeable.

Problems/Limitations

• Not possible to enable Federation Only SSO. The system sends an invitation mail that will ask people to create passwords. And even when this is avoided, when an user sign into PeopleHR for the first time (via SSO) a username/password is requested
• If employees need the mobile app, then native logins must be used

Improvements

• The UI should not say "Upload one login meta-data file". The meta-data file comes from SAML specifications
• The EntityIds must be properly checked at the PeopleHR side
• The EntityId should be configurable and definitely not carry a name as "test-app-peopleweb" as this is a production system

SAML SSO with Concur and WSO2 Identity Server

As of today, Concur supports IdP initiated SSO only. It has integration with many existing Identity providers such as OneLogin, Okta and etc .. Concur can easily work with WSO2 Identity Server (or any other SAML Provider) as well. This blog post will tell you how to configure WSO2 Identity Server with Concur Expense Management system.

Before you begin you need to get in touch with a technical contact from Concur side that will help to setup your certificate at concur side.  This is a manual step that cannot be done via online means. You MUST need the help of the technical contact at Concur side. Once you got the technical contact, here are the steps to integrate WSO2IS with Concur.

1 - Download and install the Identity Server according to the docs here. You can setup Identity Server with your cooperate LDAP store according to docs here.

2 - Now setup the Service Provider as follows.

Now the SSO should work! But you can go further to have a better integration with Concur.

Steps to go an extra mile.

3 - How can you publish a URL to the outside world as follows. http://accounts.server.com?spEntityId=concursolutions.com. Here you can add this to the internal app store of your organization and the problem is solved.

4 - If you want to provide authentication by federation only, then you can ask the technical contact to scramble the passwords and put up a banner in the page. The banner will appear like this.

5 - You can also allow users to register with authorization, but upon clicking on registration link then, the Concur admin can authorize and setup manager and additionally scramble the passwords themselves.

6 - If you want the Email link to work then the technical contact will update the link in the email so that the approvals will go the IdP first. The link will be something as follows. Please note the "hpo" and "cte" values.

https://accounts.server.com/samlsso?spEntityID=travelocity.com&hpo=4&cte=WHe$s78jMIcZE$..........OVKaiBzTI25SrSFKhSwQ7OPlB

The requirement is to insert the above values as Authorization Decision in SAML statement.

Then at the Identity Server side, I gave written an extension for SAMLAssertionBuilder to add authorization decision. What is the result? The approver will be redirected to the correct case on Approval page.