HTTPS

BridgeGate Web Service enabled as a service supports User/Password in the SOAP Header.

Authentication : This specifies whether Authentication should be performed and if so what type. NONE : No authentication will be performed by this BridgeGate Web Service.

BASIC : Choosing BASIC will reveal inputs for user name and password. These values will be stored in the workflow for comparison against values provided in the request as follows: (Note: do not confuse BASIC with “Authorization: Basic” BASIC in this scope is referring to the username / password being provided in the workflow) The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.

BridgeGate will look for 'Username' and 'Password' in the SOAP header. Example of Soap Header
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://mytest.bridgegateintl.com/websvcs/usertopersonservice/xsd">
  <soapenv:Header>
    <Username>admin</Username>
    <Password>YWRtaW4=</Password>
  </soapenv:Header>
  <soapenv:Body>
    <xsd:Root>
    <xsd:User>
     <xsd:Age>23</xsd:Age>
    </xsd:User>
   </xsd:Root>
 </soapenv:Body>
</soapenv:Envelope>

The Username field is assumed to be plain text.

The Password field is assumed to be base64 encoded.

BRIDGEGATE : The BridgeGate Web Service will authenticate the values provided in the request against the BridgeGate Users as follows: The BridgeGate Web service will use the inbound SOAP header to identify the username and password to use for authentication.

BridgeGate will look for ‘Username’ and ‘Password’ in the SOAP header. (See above example)

The Username field is assumed to be plain text.

The Password field is assumed to be base64 encoded.

The username and password will be authenticated against the BridgeGate Users and the Users must have BridgeGate Web Service portal permissions.

Failed Authentication : Results in an AXIS Fault being returned with faultcode of “401” and faultstring of “Authentication failed : Username or Password is incorrect or User does not have security rights”. Either correct the Username and/or Password and resend your request or if doing BRIDGEGATE Authentication confirm that the user has the “BridgeGate Web Service” protocol permission.

BridgeGate HTTP enabled as a service supports three ways to get the User/Password

On the URL:

http://[SERVER_URL]/portal/executeworkflow?accountName=samples&wfGroupName=bridgegate_web_auth&wfName=http_auth_get&userName=[USER]&password=[PWD]

In the HTTP header

Username   admin Password     mypassword

Authorization

Add a header key of Authorization with a value of Basic base64User:password

Authorization: Basic bXlwYXNzd29yZA==

Authenticate – when enabled, will explicitly require all inbound http transmissions to contain valid user & password credentials; also this credential must have the BGHTTP protocol rights enabled (protocol right located in the user cfg. in the Portal). Caution: when this option is not enabled , the system will allow any anonymous http transmission to the URL while the BridgeGateHTTP service is enabled. There are three places the authentication is received and in this order.

HTTP BASIC:The http header is checked for key called “Authorization”. This will have, as value the word “Basic” followed by a space or tab followed by Base64 encoded string of username:password Example of Header: Authorization: Basic bXlwYXNzd29yZA==

HTTP Header:The header is checked for keys username and password. If exists will be used to authenticate

Form Fields or URL Parameters:The URL parameters or the Form fields are checked for username, password fields

The AS2, Applicability Standard 2 for EDI, is quickly becoming one of the most secure, reliable and popular methods for sending and receiving data over the internet.   The concept for AS2 involves sending data between two points via the web within a container or envelope created by the AS2, the created certificate and public and private keys keep the information secure.  Only a few components are necessary for an organization to utilize AS2: two servers to connect; internet access; and the data to be sent and received.  The AS2 server wraps or envelopes the data, using digital encryption and certificates, which allows the data to be transmitted securely over the internet.  To clarify the role of the certificate, public and private keys within AS2 transactions review the following definitions:

The Public Key: is used to encrypt and verify digital signatures. The public key is safe to distribute to your trading partners.  The trading partner will use this key to encrypt the data that will be sent to your AS2 server.

The Private Key: is used to decrypt, digitally sign and is always kept private and protected. This key is installed in your BridgeGate key store on the AS2 server.

The Certificate: much like a driver’s license, is used for identification purposes, identifying the issuer of the certificate, show expiry and give a unique number assigned to the certificate called a serial number.  Every certificate will have its own unique serial number

This explanation of the AS2 cert/public/private key relationship and how the AS2 is used to send and receive EDI.  When an AS2 certificate is created two keys are generated which are linked together by an algorithm, one is a Private Key and one is a Public Key.  The Private Key is stored in the BridgeGate keystore on the AS2 Server, while the cert along with the Public Key is sent to the Trading Partner. The keys are then used to access the data contained within the AS2 envelope.  The following is an example of a typical AS2 exchange between BridgeGate and A-TradingPartner:

AS2 Example – Typical AS2 Process between BridgeGate and A-TradingPartner

• EDI payload is encrypted using the A-TradingPartner cert/public key (on BridgeGate AS2 server)
• EDI payload is signed using the BridgeGate (Sender) private key (on BridgeGate AS2 server)
• AS2 connection is made to the A-TradingPartner AS2 server https://a-tradingpartner.com:10443 (on BridgeGate AS2 server)
• Payload contains a request to return an MDN, either sync or async (on BridgeGate AS2 server)
• AS2 IDs/Names are used to identify the AS2 relationship (on A-TradingPartner AS2 server)
• EDI payload is decrypted using the A-TradingPartner private key (on A-TradingPartner AS2 server)
• EDI payload has its digital signature verified using the BridgeGate cert/public key (on A-TradingPartner AS2 server)
• MDN is returned with a “processed” or “Decryption failure” or “Authentication, unable to verify signature…” status (on A-TradingPartner AS2 server)

Some trading partners may issue a public certificate in a .txt format and do not communicate what certificate type it is.  One simple way to get the certificate into the format you require is it import the .txt file into Google Chrome then export it as the format you desire.

Our clients Authenticate and execute BridgeGateHTTP workflows using the Portal User Name and Password (over HTTPS ) two different ways.

First, and less common, they include the respectful key/value pairs in the URL &userName=[USER]&password=[PWD]. 

Second, they include HTTP header values as seen in the screen shot below.

The portal user must have BridgeGateHTTP Protocol security set.  If the Get Data is set to ‘Authenticate’ checked, it will require the Portal username/password.  If Authenticate is not checked, it will execute the workflow with no portal login validation.

If the BridgeGateHTTP workflow is set to authenticate and the credentials are not included, incorrect, or does not have the appropriate security permissions (BridgeGateHTTP) the client will receive a 403 error.

HTTP Status 403 – Authentication Credentials not found

HTTP Status 403 – Incorrect Login and/or Password