SOA - Changing the password periodically.

, ,
1

Hello all

Has anyone got any ideas how to handle the expiration of the password of the technical mainframe user used in stateful, “anonymous” connections?

I know RACF can relieve the user of this requirement - but not at this site.

I have the idea of creating an SQL table of current and future passwords - and letting the logon procedure update the table whenever a password change is required. There must be a better way.

The service is 24/7 so manual interactions are not on.

/Bjarne

2

Hi Bjarne,

Here’s an idea:
You may be able to just keep in the data base the date in which the last password renewal took place. When the MainFrame asks to renew a password, you use the Login path to renew the Password to a string that contains the current date inside it. Something like: myPasswrdMay042011

Then you update the DB with the current date. When you Login the next time you check the DB for the Date and construct the password out of it.

This way rather than keeping future passwords in the DB you keep a single row that specifies when was the last password renewal.

This is just an Idea, since I’m not really sure how the MainFrame behaves when a password needs to be renewed.

Please, let me know if this idea works out for you, if not we’ll try to figure out something else, if possible.

Best regards,
Ohad

3

if you are using pooled connections, you might also want to set up the password change to be proactive rather than reactive: determine what the change period is (e.g. 30 days, 90 days, whatever the policy is) and have a scheduled process do the password change a couple of days before the expiry. This would reduce the chance of an unscheduled startup causing a lockout.

4

Hi Ohad.

Good idea - but the password on the mainframe is limited to 8 characters. Keeping the date in there simply would be to easy to guess. And the SQL needed is almost the same. I was hoping for a non-SQL solution. But ApplinX still can not access regular files on the server. Shame… More ideas are very welcome.

/Bjarne

5

perhaps you could call an external web service that would manage the password input, accessing text files or a database and returning current password, change required flag, new password…

6

Hi Douglas

The idea of calling a non-ApplinX web service also has been on my mind. But creating a java application behind a web service stack simply to read and write text files sure is the long way round. But it would work too.

Does anyone have experience if it is possible to create own tables in the Derby database used by ApplinX - and how to call this table from ApplinX? Wouldn’t that be the easiest (and cheapest) way to have a “passwords” SQL table?

I would make ApplinX procedures (web services) to maintain the contents of the table.

7

I’d be reluctant to put customer tables in a product’s database, but you should be able to create another database using Derby and call that from ApplinX database procedures.

You can access the database via standard ApplinX database services (http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_ga/ApplinX/8-2-SP1_ApplinX/solutions/soaenablement.htm#databases)