I would expect that if a change such as this were to be implemented:
A) There would be some learning curve involved in implementing it but
you would only have to learn the basics of it once.
B) There "should" be no additional charge. Not having to maintain
separate authorization paradigms in each product just about has be less
expensive for the vendor. Certainly there would be an initial startup
cost, but that should be able to be amortized in a short time and then
it's all gravy :-)
Jim
Huegel, Thomas wrote:
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C83C32.6875C42E
Content-Type: text/plain;
charset="iso-8859-1"
That would be nice if A) I could easily hook my other appls into the scheme,
and B) There was no additional charge.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Alan Altmark
Sent: Tuesday, December 11, 2007 1:01 PM
To: [email protected]
Subject: Re: DIRMAINT authentication
On Tuesday, 12/11/2007 at 09:28 EST, Jim Bohnsack <[EMAIL PROTECTED]>
wrote:
What you do all think or am I the only one who thinks that this is a
problem in DIRMAINT or an "opportunity" for improvement?
To be clear, you're talking about *authorization*, not *authentication*.
As of z/VM 5.3, I think all of the most widely used servers perform
authentication via the central DMSPASS service which talks to CP or the
ESM as needed, quietly and automatically, with no pre-configuration
required.
z/VM is missing, IMO, a centralized approach to authorization. VMRM,
PerfKit, TCPIP, DFSMS, DIRMAINT, and RSCS all suffer from a parochial view
of authorization.
In z/OS, command authorization is approached by creating a structured set
of command authorizations managed by the ESM. For example, DIRMAINT might
define various authorities:
- DIRMAINT.ADMIN.FILEGET the ability to retrieve any of the DIRMAINT
config files
- DIRMAINT.ADMIN.FILEPUT the ability to DIRM FILE any config file
- DIRMAINT.HELPDESK.PWRESET the ability to reset any user's password
- DIRMAINT.HELPDESK.REVIEW the ability to look at any user's directory
(sans password)
- DIRMAINT.FOR.ALAN any (otherwise authorized) command only for user
ALAN
And so on. The ESM can apply its own conventions to those authorities.
RACF, for example, allows generic profiles such as:
- DIRMAINT.** any DIRMAINT command
- DIRMAINT.FOR.** ... against any user
- DIRMAINT.ADMIN.** any DIRMAINT administrative command not
affecting userids
- DIRMAINT.HELPDESK.** all helpdesk commands
- DIRMAINT.HELPDESK.PWRESET ACC(NONE) ...except for PWRESET
This allows you to be as generic or as specific as you like. To the
extent that authorizations are granted to named groups, simply connecting
a user to a group immediately gives the user all the authorizations
granted to the group. Set up your policy once, then apply it with a
single command for each new administrator.
While the resource access model is RACFish, it is defined by the RACROUTE
interface, the Official z/VM ESM application interface. The ESMs can have
their own implementation and rules without having to surface the RACFisms.
Alan Altmark
z/VM Development
IBM Endicott
--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]
