Saturday, March 12, 2016

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/

Sunday, January 24, 2016

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



Friday, December 4, 2015

SAML SSO with GoogleApps using WSO2 Identity Server


We are going to be using WSO2 Identity Server as the SAML provider for Google Apps. This is a valid scenario where an Organization's identity provider is an independent third party. Here is the scenario we are going to support.







Setup SAML SSO in your domain by following google documentation. https://support.google.com/a/answer/60224?hl=en

 The Sign-in page URL is in the form of, https://host:port/samlsso. The change password URL is pointed to the portal where employees use to change the password.







At WSO2 Identity Server Side, go to Main->Service Providers->Add. Now add the following configuration.
  • The ACS URL is https://www.google.com/a/test.com/acs
  • Since we have ticked the "Use a domain specific Issuer" above, our issuer is "google.com/a/test.com"
  • NameId format is "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  • Enable Assertion signing (The corresponding certificate has been uploaded in the previous step into GoogleApps)
  • Enable Single Logout and Attribute Profile

Note - test.com needs to be replaced by your actual domain name.



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.


Friday, November 27, 2015

SaaS Identity and Directory Services


For SaaS providers, what are the available mechanisms for integrating with a directory service?

  1. The LDAP can be fronted by an IdP hosted in DMZ that provides authentication and authorisation mechanisms to Cloud services. The authentication/authorisation mechanisms can be via web federation protocols such as SAML/OIDC. This is show in the above figure.

  2. The LDAP (rather a replica of it) can be exposed via "ldaps" (ssl protected ldap) to the external Cloud services

  3. The LDAP itself can be synced to the Cloud services. Technologies like Azure AD Connect can be used to implement this methodology

From 1st to 3rd mechanism, the security/privacy responsibility that lies on the SaaS provider increases.

In order to the 3rd mechanism, the users must trust the SaaS provider to store data and passwords. I believe, any organization will think twice before syncing LDAP with external parties.

So one might ask, hold on, what about online enterprise identity providers? Online identity providers such as OneLogin has obtained certifications to prove that data is private and well protected.  Obtaining such certifications are very expensive, and they needs to be maintained (audits must be done periodically).

The first mechanism can be illustrated as follows.


Wednesday, November 25, 2015

Federation Patterns - Why/How federated authentication only?



Federated authentication (SSO) and Service Provider maintained sign in can co-exist in the system, but this has account management problems. Consider your HR system has the following.


For example, when an employee leaves the organization, it is required to delete him from both places manually. This is error prone.


In order to overcome this problem, it is better if the system can give an option to disable maintaining passwords at their end, when there is an external IdP.
When an organization decides that they want federated authentication only, the system must provide a way to disable local authentication mechanisms. This means,
  • Show only the Identity Provider Sign In option in login screen
  • Forgot password link is not there in system login screen
  • Existing passwords get scrambled
  • Users cannot reset passwords from the their profile
Now comes the interesting question, how is my mobile app going to work? It can be done in One of the two ways.
  • Users can go to profile and generate a pin number for the mobile app
  • Implement SSO for mobile app. Here SAML based SSO is challenging because it is based on browser redirects but Native SSO support is available based on OIDC (Open ID Connect ) and OAuth