| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| message flow security |
« View previous topic :: View next topic » |
| Author |
Message
|
| sai kumar adduri |
 Posted: Tue Sep 03, 2013 4:08 am Post subject: message flow security |
 |
|
Acolyte
Joined: 04 Apr 2013
Posts: 73
|
Hi ,
I am trying to implement message flow security for a web service which has soap nodes.
I am using a security pep node after soap input node , while exposing the service.
I have created a security profile which is configured with LDAP server.
I am getting an error as follows:
error:
An input message to flow ''provider'' does not have an identity.
Input messages to the flow must have an identity for access.
Modify the client calling the flow to provide an identity for the message. : F:\build\slot1\S800_P\src\DataFlowEngine\MessageServices\ImbSecurityManager.cpp: 1075: ImbSecurityManager::noIdentityFound: |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Sep 03, 2013 4:16 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| sai kumar adduri |
| Posted: Tue Sep 03, 2013 4:34 am Post subject: |
|
|
Acolyte
Joined: 04 Apr 2013
Posts: 73
|
Thanks mate , this got resolved .
Is there any possibility to do this at soap input node level it self with out using any security pep node |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 03, 2013 4:37 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| sai kumar adduri wrote: |
Thanks mate , this got resolved .
Is there any possibility to do this at soap input node level it self with out using any security pep node |
The SOAPInput node is designed to do one task: receive a SOAPInput message. SOAPInput node does not provide a security decision point in or of itself. A separate security policy enforcement point is needed, hence the design and implementation of the SecurityPEP node.
Why do you not want to use the SecurityPEP node? What shortcomings do you notice about that node?
How did you resolve the problem?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| sai kumar adduri |
| Posted: Tue Sep 03, 2013 4:43 am Post subject: |
|
|
Acolyte
Joined: 04 Apr 2013
Posts: 73
|
Reason for using security pep node is to implement security in the middile of the flow .
Reason for my previous error is :
I was trying to update few changes in bar level, Some how this were not effective , hence an error .
Resolution :
I have recreated the bar and tested its working fine .
Reason for asking about the other possibility that can do this soap input node level is to get a clarity. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 03, 2013 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| The SOAPInput node is designed to do one task: receive a SOAPInput message. SOAPInput node does not provide a security decision point in or of itself. |
Yes it does. The SOAPInput node can call out to an LDAP server in the same way a SecurityPEP node can.
| lancelotlinc wrote: |
| A separate security policy enforcement point is needed, hence the design and implementation of the SecurityPEP node. |
No, the SecurityPEP node is designed and implemented for 2 principle use cases:
- where you need to make multiple checks on an inbound message
- where (as the OP does) you need to make an additional check mid-flow
If all you want is to check the WS-Security of an inbound message against an external system the SOAPInput node does that just fine & in a performant way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 03, 2013 5:10 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| The SOAPInput node is designed to do one task: receive a SOAPInput message. SOAPInput node does not provide a security decision point in or of itself. |
Yes it does. The SOAPInput node can call out to an LDAP server in the same way a SecurityPEP node can.
| lancelotlinc wrote: |
| A separate security policy enforcement point is needed, hence the design and implementation of the SecurityPEP node. |
No, the SecurityPEP node is designed and implemented for 2 principle use cases:
- where you need to make multiple checks on an inbound message
- where (as the OP does) you need to make an additional check mid-flow
If all you want is to check the WS-Security of an inbound message against an external system the SOAPInput node does that just fine & in a performant way. |
That's not just the SOAPInput node at work. I'll concede this may be more semantics. SOAPInput node by itself (in or of itself) does not authenticate user credentials, which was the question the OP asked. In order to use SOAPInput node to authenticate user credentials, other configuration is necessary:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fap04151_.htm
| Quote: |
Steps for enabling LDAP authorization:
To enable an existing message flow to perform authorization using LDAP, use the Broker Archive editor to select a security profile that has authorization enabled. You can set a security profile on a message flow or on individual input nodes. If no security profile is set for the input nodes, the setting is inherited from the setting on the message flow.
Switch to the Broker Application Development perspective.
In the Broker Development view, right-click the BAR file and then click Open with > Broker Archive Editor.
Click the Manage and Configure tab.
Click the flow or node on which you want to set the security profile. The properties that you can configure for the message flow or for the node are displayed in the Properties view.
In the Security Profile Name field, select a security profile that uses LDAP for authorization.
Save the BAR file.
For a SOAPInput node to use the identity in the WS-Security header (rather than an underlying transport identity) an appropriate policy set and bindings must also be defined and specified. For more information, see Policy sets. |
Configuring, deploying, and maintaining policy sets are somewhat onerous. SecurityPEP node is somewhat more convenient in this regard.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 03, 2013 5:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| That's not just the SOAPInput node at work. I'll concede this may be more semantics. SOAPInput node by itself (in or of itself) does not authenticate user credentials, which was the question the OP asked. In order to use SOAPInput node to authenticate user credentials, other configuration is necessary |
I think that is a bit on the hair-splitting semantics side. I conceed that you need additional configuration to point a SOAPInput node at an external server; my point was that you don't need a SOAPInput node and a SecurityPEP node to simply check WS-Security
| lancelotlinc wrote: |
| Configuring, deploying, and maintaining policy sets are somewhat onerous. SecurityPEP node is somewhat more convenient in this regard. |
I would counter that, though additional work (and onerous is in the eye of the beholder here), the advantages of holding such configuration in an external & administratively controlled artifact which can be shared & used by multiple developers in multiple situations offers an acceptable return on the time invested (we have a list of such artifacts defined against the various corporate LDAPs and developers pick one rather than attempting to define their own).
I'm also interested by your comment. My experience of SecuityPEP is somewhat limited (we mostly validate on entry) but do have a few examples where paths of a flow need additional checking. If policy sets are onerous (and as I said, they can be viewed as such) how does one avoid their use in a SecurityPEP node? It's our view the SecurityPEP node needs a security profile defined like a SOAPInput node does; are we missing a time-saving feature?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 03, 2013 5:40 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| I'm also interested by your comment. My experience of SecuityPEP is somewhat limited (we mostly validate on entry) but do have a few examples where paths of a flow need additional checking. If policy sets are onerous (and as I said, they can be viewed as such) how does one avoid their use in a SecurityPEP node? It's our view the SecurityPEP node needs a security profile defined like a SOAPInput node does; are we missing a time-saving feature? |
Only in the sense that it is conceivable one can centralize all security access through a single policy set for many sources using the SecurityPEP mechanism. It really depends on the breadth and scope of security in the organization. I have yet to fully explore this as well, as like you , I have not had the time to go down this path in a comprehensive way.
If you have several sources of security, and must configure a separate policy set for each, some efficiency can be achieved migrating those several entry points to TFIM.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 03, 2013 5:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Vitor wrote: |
| I'm also interested by your comment. My experience of SecuityPEP is somewhat limited (we mostly validate on entry) but do have a few examples where paths of a flow need additional checking. If policy sets are onerous (and as I said, they can be viewed as such) how does one avoid their use in a SecurityPEP node? It's our view the SecurityPEP node needs a security profile defined like a SOAPInput node does; are we missing a time-saving feature? |
Only in the sense that it is conceivable one can centralize all security access through a single policy set for many sources using the SecurityPEP mechanism. |
Conceptually, how would you see that centralization working? Or more specifically what advanatages have you seen using SecurityPEP rather than SOAPInput? As I said, we centralize (or attempt to centralize) access via limited policy sets used in SOAPInput and the few SecurityPEP nodes that we have. We're constrained that corporately we maintain separate LDAP systems for reasons not open to debate (the security team don't answer to anyone over which we have influence) so migrating to TFIM may be desireable but isn't going to happen. On this basis I look to you for details on making this easier.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 03, 2013 5:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| Vitor wrote: |
| I'm also interested by your comment. My experience of SecuityPEP is somewhat limited (we mostly validate on entry) but do have a few examples where paths of a flow need additional checking. If policy sets are onerous (and as I said, they can be viewed as such) how does one avoid their use in a SecurityPEP node? It's our view the SecurityPEP node needs a security profile defined like a SOAPInput node does; are we missing a time-saving feature? |
Only in the sense that it is conceivable one can centralize all security access through a single policy set for many sources using the SecurityPEP mechanism. |
Conceptually, how would you see that centralization working? Or more specifically what advanatages have you seen using SecurityPEP rather than SOAPInput? As I said, we centralize (or attempt to centralize) access via limited policy sets used in SOAPInput and the few SecurityPEP nodes that we have. We're constrained that corporately we maintain separate LDAP systems for reasons not open to debate (the security team don't answer to anyone over which we have influence) so migrating to TFIM may be desireable but isn't going to happen. On this basis I look to you for details on making this easier. |
Your current method of providing pre-configured policy set artifacts for developers and system admins to use is probably the most efficient at this level of maturity. You have reduced the administrative burden since the artifacts are (presumably) version controlled.
As the infrastructure matures, and the sources of truth multiply, the sneaker-net method may not hold up under scale. This is where I see the logic and brilliance of TFIM and the SecurityPEP node. TFIM utilizes a security cache for authentication results, which enables subsequent messages (with the same credentials) arriving at the message flow to be completed with the cached result, provided that it has not expired. This is different than using SOAPInput via multiple policy sets since those results are not cached. Caching is especially important when federating modern sources with legacy (ie mainframe) sources, since some legacy sources of truth may take a LOOONG time to return a result.
In addition, the SecurityPEP node is not limited to using TFIM. With SecurityPEP node, one can use any WS-Trust V1.3 compliant security token servers, such as those from other vendors like Microsoft and Redhat or those in the public domain.
My opinion of the SecurityPEP node is that it is an awesome addition to the toolkit and I look forward to integrating it into many of my application work flows.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 03, 2013 6:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
As the infrastructure matures, and the sources of truth multiply, the sneaker-net method may not hold up under scale. This is where I see the logic and brilliance of TFIM and the SecurityPEP node. TFIM utilizes a security cache for authentication results, which enables subsequent messages (with the same credentials) arriving at the message flow to be completed with the cached result, provided that it has not expired. This is different than using SOAPInput via multiple policy sets since those results are not cached. Caching is especially important when federating modern sources with legacy (ie mainframe) sources, since some legacy sources of truth may take a LOOONG time to return a result.
In addition, the SecurityPEP node is not limited to using TFIM. With SecurityPEP node, one can use any WS-Trust V1.3 compliant security token servers, such as those from other vendors like Microsoft and Redhat or those in the public domain. |
So the principle advantages you see derive from the use of TFIM and caching rather than the SecurityPEP per se? Given that the use of WS-Trustv1.3 is available to all the security enabled node (SOAPInput in the context of this discussion) and not just the SecurityPEP? I don't see any description of a caching mechanism internal to the SecurityPEP node which is absent from the other nodes & I agree would provide performance improvements.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 03, 2013 6:27 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
As the infrastructure matures, and the sources of truth multiply, the sneaker-net method may not hold up under scale. This is where I see the logic and brilliance of TFIM and the SecurityPEP node. TFIM utilizes a security cache for authentication results, which enables subsequent messages (with the same credentials) arriving at the message flow to be completed with the cached result, provided that it has not expired. This is different than using SOAPInput via multiple policy sets since those results are not cached. Caching is especially important when federating modern sources with legacy (ie mainframe) sources, since some legacy sources of truth may take a LOOONG time to return a result.
In addition, the SecurityPEP node is not limited to using TFIM. With SecurityPEP node, one can use any WS-Trust V1.3 compliant security token servers, such as those from other vendors like Microsoft and Redhat or those in the public domain. |
So the principle advantages you see derive from the use of TFIM and caching rather than the SecurityPEP per se? Given that the use of WS-Trustv1.3 is available to all the security enabled node (SOAPInput in the context of this discussion) and not just the SecurityPEP? I don't see any description of a caching mechanism internal to the SecurityPEP node which is absent from the other nodes & I agree would provide performance improvements. |
There are other advantages, and I'm enjoying our discussion, please continue prompting if something is not fully clear.
Using SecurityPEP, you can accept a SOAP message without rejecting it out-of-hand, do some pre-processing concerning content, possibly save the payload to a database , then authenticate against a federated source of truth, which may contain identities from mainframe, several internal user management services, and several external user management services. If the authentication succeeds, continue down the happy path. If authentication fails, perform some other processing, that may include notification to network security helpdesk, or semi-automatic human-supervised closure of some DMZ entry point automatically.
One could build a whole career on use of the SecurityPEP node, there is that much potential to be derived for highly-valued business functionality.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 03, 2013 6:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Using SecurityPEP, you can accept a SOAP message without rejecting it out-of-hand, do some pre-processing concerning content, possibly save the payload to a database , then authenticate against a federated source of truth, which may contain identities from mainframe, several internal user management services, and several external user management services. If the authentication succeeds, continue down the happy path. If authentication fails, perform some other processing, that may include notification to network security helpdesk, or semi-automatic human-supervised closure of some DMZ entry point automatically. |
It's certainly an interesting viewpoint. As a corporate standard we prefer to reject SOAP messages out of hand, possibly logging them as you suggest as part of the error process.
I'm also interested by your focus on network & DMZ as a use case. We don't use WMB in any of that; we have a wall of DataPower, Apache & other odds & ends providing that security & anything which reaches the broker estate is "clean" in those terms. Where we use SecurityPEP (and as I indicated it'a a limited use) is where we've examined the message content and are trying to route a message; an example is a transaction of a high value being sent by a user / application that doesn't have enough security permissions to transact that value, but does have authority for lower values.
Yes, it could be done with ODM & other business rules technology and probably better. It's an example, I just work here, go with me on this one. The actual use case has reasons we go against LDAP, just not entirely convincing ones.
So you've more concerned with network level authentication & proof of identity?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 03, 2013 6:52 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
My use case (as just one example) was having various DMZ devices ( DataPower , firewall , et al ) controlled by the network security console in a helpdesk someplace.
In this very specific example, which is not representative of the broader application of the SecurityPEP node capability , IIB message flow processing could notify the network security console that a need exists to terminate access on device X , Y , and Z based on some business rules or decision points it used. A human would see the alert within the network security console, and approve or disapprove the closure of a DMZ access point. If no human response within 30 seconds (for example), the network security console would take the nominated action automatically.
So the example is not using WMB for the DMZ bridge, it is using WMB/IIB as the ESB inside the secure zone and sending a nomination for action to a network security console which would then close off the DMZ access point if not overridden by human intervention.
The application of use cases for SecurityPEP node can be very broad; my example is not an exclusive focus, just an example for discussion purposes only.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
