[Info-vax] : AUTHORIZE Enhancement

[Stephen Hoffman]

On 2016-11-29 01:41:33 +0000, Kerry Main said:

> I would agree .. enterprise authentication must be capable of providing 
> SSO (single sign-on) and resource management (group policies etc.) 
> across many clustered/non-clustered systems and the industry standard 
> approach to do this for the last 2 or 3 decades has been with 
> enterprise directories / LDAP.

Single sign-on is certainly part of — but in aggregate also more than a 
few years behind — what folks are presently using LDAP for.   
Mechanisms akin to cluster-wide logical names, user mail server 
information for message routing and delivery, user contact and 
organizational information, per-user applications and preferences and 
language settings, user and group access controls and server and server 
group default security settings, all manner of details are now commonly 
stored in the directory.   Think of what is in Mail or DEC Notes and 
various other applications for preferences, but rationalized and 
centralized across all the applications and available across the entire 
organizational network.   Yes, the existing OpenVMS LDAP authentication 
support works and is reliable, though with a singularly and hilariously 
awful configuration interface, with cryptic diagnostics and debugging 
when something goes weird or when the directory doesn't quite match up 
with expectations, and — until recently, and this is thankfully now 
fixed – involved two entirely different implementations of LOGINOUT 
(and with related messages such as “To change between the frameworks of 
LOGIN and ACMELOGIN the installation of the LOGINPLUS kit will need to 
be reinitiated.”)

> Most here may be familiar with MS's Active Directory and the concept of 
> "local" accounts and "domain" accounts.
> 
> Think of sysuaf as the "local" account and the LDAP account as the 
> "domain" account.

As far as that goes, sure.   But what OpenVMS provides locally and what 
OpenVMS uses within LDAP is a very small fraction of the capabilities, 
and of what other systems already implement and use.    In short, 
"local" LDAP authentication can mean something that's rather more 
integrated and rather capable and rather more extensible than — and 
that completely replaces — the accreted morass of OpenVMS 
authentication, and the pile of files involved in a cluster.   For the 
systems I'm commonly dealing with — I am not familiar with how 
Microsoft Windows has implemented its local authentication — local 
authentication and the rest is just LDAP running locally and without 
LDAP server — or running with a self-hosted LDAP server — and is not 
operating significantly differently from how those same systems operate 
when bound to external directory servers running on other hosts.

> After implementing an enterprise directory, where most customers are 
> headed is adding IdM (Identity Management) which adds additional layers.

OpenVMS is not going to implement Enterprise Directory services.   
Sure, OpenVMS can load and run Enterprise Directory, but there's not 
going to be much customer interest in OpenVMS doing that and efforts in 
displacing Microsoft Windows Server and Active Directory from their 
central role in most organizations.   OpenVMS ceded that 
central-to-the-network position far too many years ago, and must now 
coexist with and interoperate with Active Directory or — for those 
sites using other LDAP servers — Open Directory or other services.  For 
those few sites that are solely OpenVMS, sure, load and use Enterprise 
Directory.   That service should be baked in anyway, so that local 
authentication can be migrated from the morass over to LDAP.

Third-party add-ons are not the future of OpenVMS services and 
integration.  They can be a good market for third-party providers and 
there are some excellent products available, but — like various other 
features that are now effectively table stakes in a server product – 
these and other capabilities need to be part of a baseline, integrated 
and expected and normal configuration within OpenVMS.  Always present, 
always running, it needs to be there and it needs to work.   Much like 
IP and TLS have become integral to any modern server operating system — 
OpenVMS unfortunately still treats far too many of these pieces as 
under- or un-integrated layered or add-on products, or depends on 
third-party extensions.   The morass of having to load and configure 
product dependencies, and for users and third-parties to code 
applications to figure out what's present and what's not is the way of 
pain and complexity and subtle errors and abject complexity.   Think of 
all the "fun" we've had over the years figuring out which IP stack is 
present, if any, within our documentation and our build procedures and 
management tools.  This complexity needs to end.

These capabilities — and more — are already part of systems that are 
available in the market.   This is not fantasy, not futurism and not 
even particularly difficult to do with some systems — I'm running all 
of this now, and have OpenVMS authenticating — though I'd prefer 
OpenVMS have much deeper integration — with Open Directory running on 
the servers.


-- 
Pure Personal Opinion | HoffmanLabs LLC