reviewing an issue re management of passwords led me to think about the
workbench in a more general sense.
We currently do not manage our passwords in a way that will comply with the
CII best practices.
We keep that passwords locally in a less than acceptable encrypted form.
I partially understand how to fix the issue.
But let's stand back and think about what the workbench is and where we
want to go with it.
It is a temporary beast. We want to move to a language based approach.
As a step towards that I propose we think of the workbench as an editor.
An editor that produces say WB XML files. That can then be processed on the
mainframe to generate the run control files and run the performance engine.
As such I think we should remove any password storage from the workbench
The database behind the workbench should be thought of as nothing more than
a clever scratch pad.
It remembers stuff.
Similarly the business of logging into the workbench is not really needed.
The whole user account and management of internal permissions is pretty
Simple connect to the database and a given environment. Do what you want
and export the xml.
It can then be stored in source control and re imported at a later date.
Share an environment with others. But treat the workbench just as an editor.
Agree how you are going to work together. Do not rely on the tool to sort
it for you.
Or maybe just use a local database.... that is then much more like an
This will greatly simplify it and the need for management of accounts etc,
All we need is to provide a login screen that makes a connection to the
database and takes you to the desired environment.
What about someone accidently deleting things? Yep, a valid concern. Open
to suggestions on that one.
If whatever is stored in a source control system then it can be restored.
Reply to the group with comments etc. And we can maybe discuss in our
Though I think things like this should be sorted outside of a meeting and
merely confirmed in the meeting.
Looking forward to hearing from you. We need to figure out what we are
going to do pretty soon.
The text was updated successfully, but these errors were encountered:
Having been discussing this with others an idea is to use different database schemas as the means of separating access. This can be controlled by the database itself. And thus we will not require our own management. Or need to manage the security groups.
But what about shared metadata I hear you say. Then make a schema dedicated to sharing metadata etc. And if needed migrate via export and import the data needed to a schema controlled by a given team.
Having discussed today more on the daily scrum call, we will be continuing to remove the code in the interest of making the project more agile for our code release. This discussion has been helpful because it has: (1) to reaffirm the committer responsibilities and how the project works, (2) highlighted the need for key decisions to be documented in issues for the broader community, (3) allows us to continue to consider that although we are not focused on backwards compatibility in the next release, we do not want to lose the value of our experience with our users in considering what will be of value in the future.
TSC discussion that a script at database creation will install the USER ID in the GenevaERS environment in the GenevaERS database. The workbench would prompt for a TSO USER ID and Password; the workbench would then use the TSO ID to verify that the USER ID exists in the GenevaERS database. The Workbench would also verify that the TSO PW is valid. This will assure that the person entering this ID is the person that is logging into the system. Thus the PW is never stored in the GenevaERS database; but we have not disabled all the security code.