| Author |
Message
|
| herickbeth |
 Posted: Thu Jan 31, 2013 9:52 am Post subject: Best practice setting IdentitySource (Token / Password) |
 |
|
Newbie
Joined: 31 Jan 2013
Posts: 6
|
Hello,
I would like to know the best practice (or practices used by some of you in your experience) for setting the fields IdentitySourceToken and IdentitySourcePassword on a WMB flow.
I am using the REST Api in order to start an WPS instance. For this, I have to send an HTTP Request with Basic Authentication.
It is not a good practice to hard code this token and password, but thinking about any WMB flow I don't know exactly what is the best path to follow: config file + encrypt? or querying a database +- encrypt? or any other I haven't thought yet...
I would like to hear any of your experiences (if you have one) or any opinions about this matter.
Thanx a lot for your help. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Jan 31, 2013 10:07 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
We securely serve our passwords from a web service. At start-up, we read them once from the web service. We store them in cache, and from then on, the passwords are retrieved from cache, until a web service call fails, then we re-read the password.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 31, 2013 11:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yeah, so you don't actually need to populate these in your flow.
You use security policies to attach this information to the flow using administrative tools.
So you would configure the security profile that you set on your HTTPRequest node to include the token you need to attach.
This assumes you've taken the necessary steps to secure the broker server. |
|
| Back to top |
|
|
| herickbeth |
| Posted: Fri Feb 01, 2013 7:04 am Post subject: |
|
|
Newbie
Joined: 31 Jan 2013
Posts: 6
|
Thank you so much for your replies!
Now, what I would like to ask you... in the solution proposed, where is located the token and password? In a config file? or this web service does a database query obtaining this data? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Feb 01, 2013 7:08 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
We put the UserId in a UDP so that it can be overriden at deploy time. The web service gets the pwd securely from wherever it gets the pwd securely, its a black box to us. Pwds can change in real time. We don't care what the pwd is, or where it came from, as long as it works when we need it to work.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| herickbeth |
| Posted: Fri Feb 01, 2013 7:12 am Post subject: |
|
|
Newbie
Joined: 31 Jan 2013
Posts: 6
|
Thanx a lot for your reply!
My team and I will apply this solution..
I'll keep in touch if something come up! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 01, 2013 7:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| We put the UserId in a UDP so that it can be overriden at deploy time. The web service gets the pwd securely from wherever it gets the pwd securely, its a black box to us. Pwds can change in real time. We don't care what the pwd is, or where it came from, as long as it works when we need it to work. |
Yes, again,
YOU DO NOT NEED TO DO THIS.
It can be administratively configured as part of the security profile. Which is stored on the broker machine. WHICH OF COURSE YOU HAVE SECURED. |
|
| Back to top |
|
|
| herickbeth |
| Posted: Thu Feb 07, 2013 9:32 am Post subject: |
|
|
Newbie
Joined: 31 Jan 2013
Posts: 6
|
Hey people,
I've been trying to do this solution. But I'm struggling! I have an important lack of experience with WMB solutions so I think I migth be falling apart...
Well I already understood how to get de user and password in my flow.. Now, I've been checking some information in developerWorks about how implement this security thinking of the client app that calls this WMB flow.. I found 2 solutions:
1. Using security profiles in my broker (http://www.ibm.com/developerworks/websphere/library/techarticles/1002_fan/1002_fan.html), this check the request of my header against an LDAP or TFIM, then if passes I can obtain the user and password using XPath and setting this up in my HTTPRequest node... Now, the problem is that the user and password I have to set is not located in some active directory and I started thinking how the java client that consume the flow can send this information? Because is an open application, I mean you don't have to authenticate on it to use it... this web app gets information from any person who wants to make a request to an enterprise... so I thought about another solution...
2. Using a keyStore in my web app client so then when this app calls the flow sends the user and password using WS-RM and WS-Security (http://www.ibm.com/developerworks/websphere/library/techarticles/1301_gupta/1301_gupta2.html) but this is a policy set... I don't know if this works as well... I mean applying this kind of solution... how can I get the user and password in order to make my HTTP request with authentication?...
I hope you can help with your experience! Will any of this options succeed with the solutions you explained to me before? Or do you recommend it? Or do you think another one might be better?
Thanx in advance for your helpful answers! I hope you also understand my concern hehe.. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 07, 2013 10:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ok, so the client can choose to present an identity token of some sort - there are a number of ways to do this.
If you chose to extract that token from the incoming message, you would configure a Security Profile that would handle Identity. You could also choose to configure additional aspects of that Security Profile to Authenticate that token and then to Authorize that token using some kind of store that holds authentication and authorization information (an ldap, TFIM/etc.).
If you wish to manually extract that token and process it manually in Broker, you can also do that, provided you know how to write the necessary code.
If you wish to propagate that token out of the message flow to downstream resources, you would ensure that the Security Profile supports that.
If you wish to Map the incoming token to a new token (validate incoming clients as individuals, make all outgoing requests as 'the broker' instead of the individual), you would either configure the LDAP/TFIM/etc to handle that mapping, or you would use logic in your flow to set the IdentityMapped fields in Property. You can also configure the Security Profile to pass a specific, known ID - that again, is stored in the Profile.
If you wish to do any of this using Web Services Security, you will configure a Policy Set and Policy that will provide additional information to the Security Profile about where tokens live, how to extract and populate them, and to specify information about fixed, known identities. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 07, 2013 2:52 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
At some prompting, I will clarify the above a bit.
All of the stuff about Authentication, Authorization, and Mapping has to do with an *incoming* token being presented *TO* Broker.
It has nothing to do with Tokens that Broker itself passes for outgoing requests.
Well. The functions for securely mapping one token to another does have to do with outbound tokens. But the whole point of that is to manage to do it more securely. You can still choose to configure Identity Propagation only, without requiring any external security provider, and write your own logic to take the value of IdentitySource tokens and populate the correct values for IdentityMapped tokens.
But you're very very likely to reinvent a much less secure solution than if you used an external security provider. |
|
| Back to top |
|
|
|
|
