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: IBMVM@LISTSERV.UARK.EDU 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
