> You would not write a "*RPI to PAM bridge widget". *RPI is > how the ESM provides services to the control program, not guests.
I think we may have missed purposes in the fog here. I think you probably would need to write a small *RPI bridge application, since the idea was a Q&D way to allow CP to directly use authentication methods like Kerberos for authentication, etc without having to port every possible authentication method to CMS. Guest ESM gets request from CP, runs it through it's PAM stack to decide how to answer the query from CP, and passes the info back to CP. You'd have to write something that decoded the request from CP, presented it to PAM, and returned the results in the format CP is looking for. > The underlying communications mechanism to request services > from the ESM is not architected. And rather than architect > Yet Another Proprietary Interface, the better solution is for > the ESM to provide LDAP-based authentication services. Then > any guest or remote host can access the service. You know, that's really a big missing piece of basic architecture. That approach assumes that there is a functioning network, or that IP connectivity to the ESM is even desirable -- lots of places for failures to occur. Also, why should every ESM have to reinvent the API? Wasn't that the point of RACROUTE? I'd argue that focusing on the ESMs all individually implementing a authentication method is actually a mistake; having a clean, non-network dependent method of passing requests to the currently configured CP ESM is more scalable, more secure, and more flexible. It's also more compatible with extending a abstract model of presenting security and security associations to different architectures (cf WS-Security or Kerberos, etc). It also assumes that all vendors will implement (or even agree on) the same schemas, which at the moment, is not the case. Try something as simple as authenticating a RH server against the SuSE LDAP server -- even two Linux distributions don't completely agree on the schemas, let alone arbitrary OSes. > But, yes, you could write a new PAM that uses a non-standard > interface to request ESM services. Just a interface with the PAM module stack. The point of PAM is a framework to handle specific AAA methods w/o rewriting the applications. As to non-standard, you've just told us that you haven't established a standard, so how can it be "non-standard"? ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
