Documentation Index

Fetch the complete documentation index at: https://help.idibilling.com/llms.txt

Use this file to discover all available pages before exploring further.

IDI version 26.8 is now available.  Click here for details: IDI Updates.

Understanding Authentication

Prev Next

In order to develop to IDI’s web services, a developer must be able to properly authenticate.  The goal of this post is to explain what is involved in understanding this crucial requirement.

IP ORIGINATION

IDI’s web services are protected by IP origination.  If you are unable to load https://api.idibilling.com from a browser, your client IP is blocked.  Contact your IDI Billing representative to have the required IP’s added.

WEB SERVICE REQUESTS

Each request to an IDI web services requires proper authentication. Depending on the endpoint the authentication may be different.

  • The SOAP-based endpoints require a SAML token from IDI’s Security Token Service AND the request must be signed using XML DSig

  • REST-based endpoints use a Simple Web Token (SWT)

For both of these methods, a proper username and password is required.  For web service authentication, a specific user type is required.  Contact your IDI Billing representative if you need this username or password.  The user is usually in the format:  XYZ_ws_user.

OBTAINING A SAML TOKEN

The SAML token is requested via the Security Token Service Issue method.  The request should look similar to the below XML with the following values replaced:

  • {USERNAME} – replace with the web service user

  • {PASSWORD} – replace with the password for the specified web service user

  • {STS_URL} – URL of the Security Token Service, like https://api.idibilling.com/SecurityToken/1X/xyz01_T_TEST

  • {APPLIES_TO}  – this is most likely to be the string: http://idibilling.com/webservices

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:ns2="http://www.w3.org/2005/08/addressing">
<env:Header>
    <ns2:Action env:mustUnderstand="1">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</ns2:Action>
    <ns2:To env:mustUnderstand="1">{STS_URL}</ns2:To>
    <o:Security xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
    <o:UsernameToken>
        <o:Username>{USERNAME}</o:Username>
        <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{PASSWORD}</o:Password>
    </o:UsernameToken>
</o:Security>
</env:Header>
<env:Body>
    <trust:RequestSecurityToken xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <ns2:EndpointReference>
        <ns2:Address>{APPLIES_TO}</ns2:Address>
    </ns2:EndpointReference>
</wsp:AppliesTo>
<trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
</trust:RequestSecurityToken>
</env:Body>
</env:Envelope>

A valid response would return a SAML token that can be used for subsequent calls.