Evaluating Business Intelligence tool for embedded analytics and reporting

Business intelligence (BI) tools are a way for companies to generate business insights – necessary components in making smarter, better decisions that drive results. There are many types of BI tools, from business analytics and big data statistics to reporting tools and dashboards that offer at-a-glance information across indicators.
 Most of the organizations would like to integrate the BI tool into the Portal of their product at some stage. When we do research on BI tools, we generally tend to focus on functional capabilities of the tool,  forgetting or giving low importance to critical evaluation parameters from embedding perspective.
Based on my recent experience of evaluating BI tools, most of the BI tools having fairly competing functional capabilities.If you are planning to embed the BI tool within your product at any stage, you should focus on integration capabilities of the BI tool. I have tried to cover the technical considerations from embedding perspective below.
As the current trend is is focusing on Web/HTML portal, we have to look at integration at 2 integration points, Presentation Tier and Services Tier. 

Services Tier Integration :

• Technology Consideration: This is the most critical aspect for integration. Question to ask is "Does the integration requires any specific technology like Java?". If yes, does the technology has any specific version requirement and it fits with technology of Product. 
• API's integration: API based integration provides the best possible integration as it removes any technology dependencies. If the API based integration is possible, check below points
• Documentation of the API - Are the API documentation provides easy and detailed information about the APIs
• API Security : Are API's secure. Do you need any specific authentication mechanism to invoke the APIs.
• API end points completeness: Check if the exposed API provides good enough endpoints to allow complete/automated integration.
• Versioning of API: Are API's versioned. Versioning helps immensely during BI tool upgrade as this avoids the need of updating the product code immediately.
• Authentication Integration: Authentication is another important aspect for integration. The points to consider largely depends on authentication mechanism supported by the product and deployment model (On Premise vs Saas/Cloud) of the product
• LDAP/AD based authentication: This integration mechanism is generally simplest but useful only if 
• your product deployment is On premise and supports LDAP/AD based authentication
• your product deployment is in private/public cloud and do not provide SSO with End customer but only LDAP/AD authentication. If your product supports SSO this mechanism can not be used as LDAP/AD must in be private network of End customer which can not be used by BI tool.
•  SSO or Ticket based Authentication : This integration is generally complex but does not have tight coupling with products own authentication mechanism.Product continues to provide the authentication. Additionally BI tool authorizes the already authenticated user  and provides token/ticket for further integration

Check the authentication mechanisms supported by BI tools, compatibility with Products existing authentication mechanism and efforts required for integration

Presentation Tier Integration 

Note: The points explained below are considering your front-end is based on HTML/JavaScript.

• Technology Consideration : Interestingly technology consideration for front-end is exactly reverse of back-end. With front end we can not create the context of same technology multiple times in the same document. So if your technology clashes with the technology used by BI tool, then it will be a big problem. Even if the versions are same right now, it can not be guaranteed in future releases of your product or BI tool. So Make sure that the BI tool does not have dependency of any of the modern technologies like AnguarJs, EmberJs or at least on the technology that you are using.
• JavaScript API for Integration : Check whether BI tool provides JavaScript API for embedding BI content in your portal or the integration is based on IFrame. It is best to have JavaScript based integration as IFrame based integration can have severe limitations and also more complex integration.

Although this is not the exhaustive list of evaluation criteria I hope this will help you to make initial evaluations of the BI tool. 

Next blog I will try to cover on Deployment considerations for BI tool evaluation. 

Test SAML Generation

Recently I was working on providing SAML based SSO support for Spring application. The requirement was to provide IDP initiated SSO support. One of the major challenge was how to generate a Test SAML for testing the integration without real IDP. This post talks about the steps to generate test SAML without real IDP. 

1. Download the SAML template from either of these locations
• Option 1: The SAML template can be downloaded from https://www.samltool.com/generic_sso_res.php. Download An unsigned SAML Response with an unsigned Assertion as we have to modify the SAML. Lets call this Template 1 henceforth
• Option 2: Download the template from Github . Lets call this template 2.
2.  Specify the Destination in the SAML. This is the location of Service Provider (SP). This should match the Location value of AssertionConsumerService tag of your SP metadata 
• Template 1 : Substitute the value of Destination attribute of  samlp:Response element with  the location of your SP.
• Template 2 : Substitute <<Destination>> with the location of your SP.
3. Specify the issuer of the Saml. This should match the entityID from IDP metadata
• Template 1: Replace the value of tag <saml:Issuer> with the entityID from IDP metadata.
• Template 2 : Substitute <<Issuer>> with the entityID from IDP metadata.
4.  Specify the Recipient. This should match with the Destination specified in step 2 above
• Template 1: Specify the value of Recipient attribute of  saml:SubjectConfirmationData tag 
• Template 2: Substitute <<Recipient>> with the value as specified in step 2
5. Specify the Audience. This value should match the entityId in the SP metadata
• Template 1: Specify the value of saml:Audience tag to match the entityId in SP metadata
• Template 2: Substitute the <<Audience>> with the value to match the entityId in the SP metadata
6. Specify the Certificate date validity attributes. The date value should be matching to your SPs current time. The time difference should not be greater than response skewness value specified in your SAML validator. Generally the skewness value is 60 sec. The date should be in this format 2024-01-18T06:21:48Z
• Template 1: Specify the appropriate value for these attributes IssueInstant (multiple instances), NotBefore,  AuthnInstant. 
• Template 2: Substitute <<IssueDate>> with appropriate value.
7. InResponseTo signifies that SAMLRequest from SP had that value and IDP is sending a response to that request. As we are working on SAML response for IDP initiated response, the InResponseTo attribute should not be present.
• Template 1: Remove all the instances of InResponseTo attribute
• Template 2: It's already removed so no action is required.
8. As the saml response is ready, next step is to sign the response. To sign the response, we need Private certificate and Public Certificate.
• Creating Public and Private Key
#create the keypair 
openssl req -new -x509 -days 3652 -nodes -out saml.crt -keyout saml.pem 


#convert the private key to pkcs8 format 
openssl pkcs8 -topk8 -inform PEM -outform DER -in saml.pem -out saml.pkcs8 -nocrypt
• Go to  https://www.samltool.com/sign_response.php. Copy the XML generated in step 7 and certificate generated in above step to appropriate input boxes and click Sign XML.
9. Next step is Encoding the Signed Certificate. Go to https://www.samltool.com/base64.php. Copy the XML generated in Step 8 to XML to be Base64 Encode input box and Click Base64 Encode XML button. The output of Base64 Encoded XML input box is the encoded SAML assertion.
10. Next Step is creating an HTML page to submit the SAML assertion to SP endpoint.
• Download the HTML template from Github
• Substitute <<SPEndPoint>> with the SSO URL of the application that you plan to access 
• Substitute the <<SAMLEncodedToken>> with the SAML assertion received in step 9 above.
11. As you load the above HTML page in any browser SAML token is submitted to SP endpoint and if authentication is successful, appropriate secured page is shown.

Happy SAML.