BMC Communities Banner

This Question is Answered

1 "helpful" answer available (5 pts)
5 Replies Last post: Nov 10, 2009 10:14 AM by relliott  
Annu Participant 15 posts since
Oct 29, 2009
Currently Being Moderated

Oct 29, 2009 1:07 AM

Disabling default security feature in AO

Hi All,

 

I am new to the BMC products and have recently been trying to work with the Atrium Orchestrator. My question is:

 

AO has a default security feature which mandates the presence of "SecurityHeader" in the incoming Soap request. In some scenarios, it might not be possible for the incoming request to carry all the security information.

Is it possible to disable this feature in AO so that any request without the secure header could be consumed?

If yes, then How? Else where can I find more information on the same.

 

Thanks in Advance,

Annu

Jake Morgan HotShot 192 posts since
Jan 26, 2007
Currently Being Moderated
1. Oct 30, 2009 5:28 AM in response to: Annu
Re: Disabling default security feature in AO

Look in the 3.0 documentation series on the BMC support site for Web Services User Guide

Jake Morgan HotShot 192 posts since
Jan 26, 2007
Currently Being Moderated
3. Nov 3, 2009 9:08 PM in response to: Annu
Re: Disabling default security feature in AO

I'm not aware of a method that allows you to acheive this. What is the use case for an un-athenticated web service call?

relliott HotShot 64 posts since
Feb 12, 2008
Currently Being Moderated
5. Nov 10, 2009 10:15 AM in response to: Annu
Re: Disabling default security feature in AO

Annu,

 

What you are trying to do here is not within the default realm/capabilities of any packaged product?

 

You are looking at having to write a SOAP/Web Services Bridge between your source application and Atrium Orchestrator where the bridge simulates the Web Service Operations 100% that the source system (which you state cannot change) is expecting.  The Bridge would then turn around and execute the call against AO, get a response, and then reply back to the source system in the format it is expecting.

 

You are looking at having to write the Bridge in a low level language such as Java, or .Net, and I would question the overall design of this approach as well as its resilience to failure etc...

 

Unless you have the expertise available to build the Bridge in one of these languages then I would suggest you find an alternative approach, by either modifying the source system to be able to call AO directly, or finding an alternate communication mechanism (such as SNMP Traps, Polled Database Table, Flat File, Email, MQ/JMS etc...)

 

Robin.

Advertisement

More Like This

  • Retrieving data ...