Jump to content

    Vikas Kumar 9

    plug-icon_2.png.3251ad9b46725e4ab223735e8ff90801.pngAPI's in General - Overview

    TIBCO® BPM API's available as API Explorer and ready to use Client Application Development Features.

    Any Integration can be implemented using Server or Client-Side APIs from scratch.

    Using the Client Application Development comes with a lot of Benefits, e.g.

    • custom code simplification
    • quick to learn and implement
    • no need to learn all detailed API calls to achieve a goal
    • officially supported
    • quick execution
    • minimize Project Risk 


    Single Sign-On (SSO)

    This is a big topic and is not something that can be done effectively or securely without understanding the underlying mechanisms being employed. For SSO with TIBCO® BPM the following mechanisms are supported:

    TIBCO BPM Enterprise 5.x supports the following types of Authentication:

    • Basic Authentication- The credentials used for authentication is obtained from the HTTP request in the form of user name and password. The user name and password are authenticated against an LDAP.
    • SAML Web Profile - If your TIBCO BPM Enterprise application is configured to use SAML Web Profile for authentication, users of your application can log in using a user name and password issued by an Identity Provider (IdP) that supports SAML Web Profile.
    • OpenID Connect - If your TIBCO BPM Enterprise application is configured to use OpenID Connect, users of your application can log in using a user name and password issued by an Identity Provider (IdP) that supports OpenID Connect.

    UI Side of Single Sign-On mechanisms

    SPNEGO/Kerberos (Windows) and Siteminder work with web UI clients and therefore also with REST APIs. SPNEGO/Kerberos is primarily useful for browser support on a Microsoft platform. However, getting this working is hard. It is however a really neat way of doing SSO for end users if you have everything configured correctly and running a compatible browser on a windows box and authenticating against the same ActiveDirectory (AD) that is used by TIBCO ActiveMatrix® BPM 4.x for its LDAP. This configuration extensively depends on the way customers have implemented their AD architecture. Get someone who knows about this customer AD and Kerberos involved if you want a stress free implementation of this capability. 

    API Side of UI Side of Single Sign-On mechanisms

    With TIBCO® BPM Enterprise 5.x users of your application can log in using a user name and password issued by an Identity Provider (IdP) that supports SAML Web Profile.


    SAML and X509 as far as TIBCO ActiveMatrix® BPM 4.x is concerned are for SOAP only. From a client perspective, ADFS and WIF will do both. The thing to watch out for here is the certificate requirements. X509 is much more complex because the certificate management parts of this are hard and the management aspects of this technology may not be acceptable to customers. SAML is much easier to deal with. The SAML profile ActiveMatrix is using is "sender vouches", which means that an IDP is not needed, just the capability to sign messages in the required way is necessary. 


    The difficulties with all of this are not with ActiveMatrix® or ActiveMatrix® BPM 4.x or TIBCO BPM Enterprise 5.0, but simply because SSO authentication is a difficult topic. By far the simplest mechanism mentioned above is SAML with SOAP because it is "sender vouches". and only requires the sender to be able to appropriately sign the SOAP/REST messages, which only requires access to the correct certificate.  

    BTW, there is no option to just turn off authentication. This would be a terrible security vulnerability. Even the option to be able to turn this off would be considered a vulnerability. 

    SAML Security

    SAML Validation in TIBCO® BPM Enterprise 5.x and TIBCO ActiveMatrix® BPM 4.x (AMX BPM) has 2 parts

    Authentication:: BPM validates the user based on its SAML Token and would do the Authentication /Authorisation based on the SAML Token provided. This can create security threats as any user/application can create a SAML token and call the BPM Services, to overcome this issue the Integrity is Mandatory.

    Integrity:: Integrity is maintained through the X509 signing of the Security header as well as the whole body of the message, in e.g. a TIBCO BusinessWorks? (BW) scenario sign the Security Header and Body using its Private Certificate. BPM will have the corresponding Public certificate in its trust store to validate the message.

    Consider the following security threats


    Request from a source other than BW In this case the request would be rejected by BPM, as BPM cannot validate the Caller (BPM will not have the Public certificate for the unknown Source) In Case of Network phishing the request from BW to BPM is intercepted by a third party and altered, this request would also be rejected by BPM, because the hash code created for the initially body send by BW will not be corresponding to the updated Body by the third party.


    Any contribution is welcome!

    back_19.png.1d5811eb9759b02bee6176faac9331dd.pngBack to Main TIBCO® BPM - User-Interfaces Wiki page

    User Feedback

    Recommended Comments

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Create New...