Thanks..
Have you successfully used the Atrium WS Registry to dynamically use
EndPoints as well as authentication information? Specifically on AR System
server 7.6.03?
The configuration I built for storing authentication information works quite
well. I tested it after encrypting the password with a auto generated GUID
that I created as an encryption key (hidden), and it works like a charm.. I
was hoping to be able to use the EndPoint too as a parameter, but that
doesn't work as it breaks its references to the WS fields.
For now I'm just happy that I do not have to store the password as clear
text on the configuration form. Sure it can be hacked if the encryption key
is known, but since I'm using a GUID for the encryption key, it just adds a
small layer of protection since a GUID is not quite human readable at a
glance..
I still wish there was a better way of doing this... hence my posting to the
list in the hope someone has attempted a better design..
Joe
-----Original Message-----
From: Grooms, Frederick W
Sent: Friday, April 20, 2012 4:02 PM Newsgroups:
public.remedy.arsystem.general
To: [email protected]
Subject: Re: Storing and using passwords (not Remedy User password) through
workflow....
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"
