The "ditch medicine" approach we used for some accounting web service calls seemed to work OK and passed the customer's security groups scrutiny.
It was a bit more complex than just a straight up, out of the box web service but we avoided huge infrastructure adaptations for the sake of better "proper" security.
The process was basically a handshake. The intent was to prohibit non-authorized calls to the provider WS that would effect a data breach. This is a bit tricky to explain without a diagram but I'll give it a go.
Consumer "Domino" makes an initial request to provider "Warehouse" with an initial account key.
This kicks off a process on the provider which immediately connects back to the known Domino application that should be allowed to request account data, calling a separate domino provider webservice that receives the accounting information and stores it in a secure database, returning the docid to provider "Warehouse".
The response docid is the response sent back to consumer "Domino" as a response to the initial ws call.
This is all a synchronous event that takes less than a second (inside a corporate network). The initial domino consumer does a lookup within the secure db, using Domino credentials, to find the document id returned from the data warehouse provider response and then pulls the accounting information into the UI.
Yes - a UI display of results after all that bouncing around.
So, abbreviated:
D (account number)->
W (accounting codes)->
D (doc id)->
W (doc id)->
D (dblookup with doc id) ->
D (accounting codes)->
web UI
So we got past the authentication by ensuring a call to the provider could only return a piece of information that was useful only to the correct consumer and the consumer, the domino app, was the only process id (agent signer) with proper access to the deposited data.
It was complicated, but it worked fast enough and got us around the need for both SSL and some form of authentication.
The "ditch medicine" approach we used for some accounting web service calls seemed to work OK and passed the customer's security groups scrutiny.
It was a bit more complex than just a straight up, out of the box web service but we avoided huge infrastructure adaptations for the sake of better "proper" security.
The process was basically a handshake. The intent was to prohibit non-authorized calls to the provider WS that would effect a data breach. This is a bit tricky to explain without a diagram but I'll give it a go.
Consumer "Domino" makes an initial request to provider "Warehouse" with an initial account key.
This kicks off a process on the provider which immediately connects back to the known Domino application that should be allowed to request account data, calling a separate domino provider webservice that receives the accounting information and stores it in a secure database, returning the docid to provider "Warehouse".
The response docid is the response sent back to consumer "Domino" as a response to the initial ws call.
This is all a synchronous event that takes less than a second (inside a corporate network). The initial domino consumer does a lookup within the secure db, using Domino credentials, to find the document id returned from the data warehouse provider response and then pulls the accounting information into the UI.
Yes - a UI display of results after all that bouncing around.
So, abbreviated:
D (account number)->
W (accounting codes)->
D (doc id)->
W (doc id)->
D (dblookup with doc id) ->
D (accounting codes)->
web UI
So we got past the authentication by ensuring a call to the provider could only return a piece of information that was useful only to the correct consumer and the consumer, the domino app, was the only process id (agent signer) with proper access to the deposited data.
It was complicated, but it worked fast enough and got us around the need for both SSL and some form of authentication.