[omniORB] Access control

[Gustavo Niemeyer]

Thanks for writing Renzo! You seem to be the only one interested
in that matter. :-)

>     we planned to add full security to our working platform based on
> OmniORB. Because of practical reasons, we didn't even consider the Security
> COSS (too complex and convoluted).

Yes, I found the same thing here. It offers too much functionality, with
too little utility. :-)

> Basically, we want to provide authentication/authorization features so
> that Sesame appeared the best candidate to borrow ideas from (Kerberos
> deals with authentication only). Authentication by the public key
> version of Needham-Schroeder, authorization by role-bound privileges
> to be added to ticket contexts.

I have never heard about Sesame before. After reading your message I
looked for it, and seems to be something similar to what I had in mind.
The role approach works well for almost everything.

> The overall layout must be based on PK technology.

That part will probably be implemented in a different way here. I need
the username/password approach. Kerberos would be good enough for the
authentication part, with some backing database, as you describe.

> Things are even more complicated by partial overlapping between IDL
> and ASN.1, so that a mixed approach seems the best. We prefer to
> design private things such as tickets in IDL, while certificate
> management must stay on the ASN.1 side, just to avoid rehinventing the
> wheel.

Agreed.

> The overall design must heavily rely on OmniORB 4.0 interceptors (for
> tickets) and transports (for encryption).

Interceptors are only able to do the basic authentication (accept/deny),
right? How do you limit the functionality allowed for different clients?
One of the problems I wasn't able to figure out is how to deal with
"forkings" in the code, depending on the client. For example, both
clients are able to ask for a given method, but the method acts
differently depending on who is accessing. I probably haven't figured
out the full power of interceptors. I must have a look at omniorb
internals (or find some good documentation).

> We already use a database pair to support the infrastructure: a
> registry for configuration/administration purposes (in place of the
> naming service, quite insufficient for our goals), and a security db
> for keeping users, hierarchical roles, and an ISO-style symbol
> library.

You seem to be quite advanced on that matter. I'm still thinking about
how to implement that features without shooting my foot in the future.
Even CORBA usage isn't set in stone yet, but given the project
requisites, it's becoming an obvious path.

> Encryption is the missing feature - we planned to add it as soon as we move
> to 4.0.

Yes, should be straightforward with SSL now.

Thank you one more time!

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]