Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workbench Passwords Removal Proposal #99

Open
KipTwitchell opened this issue Feb 19, 2021 · 5 comments
Open

Workbench Passwords Removal Proposal #99

KipTwitchell opened this issue Feb 19, 2021 · 5 comments
Assignees

Comments

@KipTwitchell
Copy link
Member

@KipTwitchell KipTwitchell commented Feb 19, 2021

A message was sent to the group https://lists.openmainframeproject.org/g/genevaers-discussion from hammyau@gmail.com that needs to be approved.

View this message online

Subject: Workbench

Hi All,

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.
Nothing more.
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
system.
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
pointless.
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
editor?

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
coming meetings.
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.

Cheers,

Ian C

@michael-shapiro
Copy link

@michael-shapiro michael-shapiro commented Feb 26, 2021

Based on my experience, a workbench should have a feature to control a user access to the different components. I think we should find a way to keep it.

@hammyau
Copy link
Member

@hammyau hammyau commented Feb 27, 2021

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.

@KipTwitchell
Copy link
Member Author

@KipTwitchell KipTwitchell commented Mar 1, 2021

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.

@AOrthVector AOrthVector closed this Mar 1, 2021
@AOrthVector AOrthVector reopened this Mar 8, 2021
@AOrthVector
Copy link
Contributor

@AOrthVector AOrthVector commented Mar 8, 2021

re-opened for discussion at 3/9 TSC meeting

@KipTwitchell
Copy link
Member Author

@KipTwitchell KipTwitchell commented Mar 10, 2021

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.

Passed by the slimmest of margins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants