> The need to do an IUCV connection adds a lot of complexity we don't > need.
As complexes of systems get larger, then depending on synchronizing local caches of authorization information becomes a (n**2-1) problem. You also need a level of abstraction -- given the demo of "VMPlex" that has been shown at SHARE and elsewhere, there will need to be arbitration of who answers the question in a multimode complex if we are to get a true single-system image. > I think that if we want even locally written tools to exploit > this, a CP command would be better. Even if that means it becomes a > synchronous interface. So > CP CANYOUDO <resource name> <access mode> I think the user-space presentation is orthogonal to the internal function. Internally, the command could contact an authorization service, which may be on the local node or elsewhere in the cluster if the admin so chooses. You could permit caching for speed, although that could get complicated in terms of rule expiration or changes in authorization profiles during a login session. What about: CP TEST <resource> <operation> RC=0 if operation permitted, RC=28 if not permitted, RC=some high number if there was an error getting an answer. > > IUCV has the advantage that it can already be transported across ISFC, > > which would allow concentrating authorization information on certain > > nodes in a cluster, a useful scalability and auditability feature. > > I think it would be enough to get CP's answer on *this* system, > whatever way CP has come to that conclusion. If CP would trust to > connect to the ESM via ISFC, then CP may use that... Hmm. What about a hybrid model: if CP joins an ISFC cluster, part of the cluster initialization exchange could include the presence or absence of a central authorization service. If present, each CP could connect and notify the service of its presence and a IUCV node and target to connect to. The authorization service (wherever it resided) could then connect back to the supplied target and populate a local cache of authorization rules. In this scenario, if you had a central authorization system, you could supply a timeout for each entry or push updates at any time (assuming that CP sorted the cache by "freshness" of an entry). At or near expiration of an entry, that node could contact the auth service and slurp down a fresh set of rules into a separate table, then flip over to the new set for minimal exposure to a "no rule for that" setup. You could then create a DIAG to validate a test against the local authorization cache -- which would be easy to use to implement the local CP command you suggested, but also allow the scale-up I'm looking for.
