No documentation other than what is in the Integration doc. I originally was trying to use it so I didn't have to have separate filters for each environment (Dev, Test, Prod). I could never get anything to publish to the registry
Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe Martin D'Souza Sent: Friday, April 20, 2012 2:39 PM To: [email protected] Subject: Re: Storing and using passwords (not Remedy User password) through workflow.... Fred, Thanks for your response.. I am glad you brought this up as this would be my concern sooner or later.. I am not using the EndPoint dynamically as yet, although that is the direction I want to go to ultimately, hence the inclusion of the URI and EndPoint fields on that configuration form I have built. I have not yet used the WS Registry in any of the WS related work I have done so far. Do you have any good documentation on that? Part 1 of what I wanted to do was to dynamically use usernames and password and not have them hardcoded as that would mean changing workflow every time the password came up for a change.. URI's and EndPoints are less likely to change that often hence my intent to leave that for later. Joe -----Original Message----- From: Grooms, Frederick W Sent: Friday, April 20, 2012 2:18 PM Newsgroups: public.remedy.arsystem.general To: [email protected] Subject: Re: Storing and using passwords (not Remedy User password) through workflow.... In order to dynamically set the EndPoint with your Set Fields from Web Services Filter you would have to use the WS Registry Integration (I looked and BMC did not add in to allow you to use a regular field for the endpoint in the Web Services action. The only dynamic method uses the registry) Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe Martin D'Souza Sent: Friday, April 20, 2012 12:06 PM To: [email protected] Subject: Storing and using passwords (not Remedy User password) through workflow.... ** I’m wondering if any of you had done this and what solution you used.. The requirement is simple.. I am using a WSDL that needs to be authenticated using a username and a password. I do not like the idea of hardcoding this into my filters for various reasons, the biggest being that if these credentials were changed, I would need to change all the workflow that has WSDL set fields action causing major caching.. Also it’s a bad design to do something like that.. The other reason is our Remedy admins would not need to worry about maintaining the WSDL password changes which would be set in that configuration form by the WSDL administrators when they change that password and these administrators on our site are not Remedy administrators... So was designing a concept of a ‘web service integration configuration form’ that stores this information. The form currently has these fields:- Field 1: Web Service server name Field 2: Port Field 3: Context Path Field 4: Based on the above generates URI Field 5: Based on the above generates EndPoint Field 6: Authentication User Field 7: Password Method 1 (which failed – as I expected it to) I used the reserved field ID 102 for a password. However when this is used in a set field operation in a Filter to call the web service, the authentication fails because the password used is still encrypted. (If this had worked, I may have actually raised it as a bug or security threat lol) Method 2 (work in progress which should work) I intend to use a generic field ID with an edit mask on its display type, and use the ENCRYPT and DECRYPT functions in a filter to encrypt the contents of that field. So I would create a new Field 8: Encryption Key, that allows the WSDL admins to set an encryption key, so that their passwords will be encrypted and stored in the database. So the form would now have the following fields:- Field 1: Web Service server name Field 2: Port Field 3: Context Path Field 4: Based on the above generates URI Field 5: Based on the above generates EndPoint Field 6: Authentication User Field 7: Password Field 8: Encryption Key To make it fancy I could mask both and encrypt both the user name as well as password so we as AR Admins would not even know the user they are using for the authentication (unless we see the plugin logs :-) ).. But for the moment I’ll leave the username as clear text, as I don’t see the point of masking and encrypting both.. This (encrypting the password or both username and password and decrypting them for use) should work as it’s a fairly simple process.. While it does look secure, it is ultimately possible to get the user and password they are using from the plugin logs. But at least not directly so there is a certain amount of security.. What methods do you’ll use in case you’ll had similar needs? Any better methods or practices? Joe _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
