[omniORB] omniORB Authentication Methods

[Stephan February]

Hello Everyone

I have been doing a bit of reading on various authentication methods with
CORBA in general, and omniORB specifically. The two methods I've found so
far are:

- Enforcing a single access point (based on a paper titled "Architectural
Patterns for Enabling Application Security")
I am thinking that using Custom Servant Managers allows one to achieve
this.

- Adding an authentication token as a Service Context in a *
clientSendRequest* Interceptor.

Has anyone implemented either of these two methods in production? What are
your experiences ?

Regards
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061011/47ea878e/attachment.htm

[Duncan Grisby]

Post by Stephan February
I have been doing a bit of reading on various authentication methods with
CORBA in general, and omniORB specifically. The two methods I've found so
- Enforcing a single access point (based on a paper titled "Architectural
Patterns for Enabling Application Security")
I am thinking that using Custom Servant Managers allows one to achieve
this.

I'm not sure what that means. Can you explain?

Post by Stephan February
- Adding an authentication token as a Service Context in a *
clientSendRequest* Interceptor.

This definitely works. I'm using it in production, and it doesn't cause
any problems.

Cheers,

Duncan.

[Stephan February]

Post by Stephan February
- Enforcing a single access point (based on a paper titled
"Architectural

Post by Stephan February
Patterns for Enabling Application Security")
I am thinking that using Custom Servant Managers allows one to

achieve

Post by Stephan February
this.

I'm not sure what that means. Can you explain?

The Single Access Point design pattern is explained in this paper:
http://st-www.cs.uiuc.edu/~hanmer/PLoP-97/Proceedings/yoder.pdf<http://st-www.cs.uiuc.edu/%7Ehanmer/PLoP-97/Proceedings/yoder.pdf>

In my implementation I intend to :
a) Create my own POA
b) Create a custom servant manager for POA in (a)
c) Enforce Role Based Access Controls against (oid, operation) tuple in
the preinvoke() method
of the servant manager. i.e. Refuse to return a servant object for
which a user does not
have appropriate privileges.

Do you forsee any problems with this approach (other then that all my
servants *must* be registered with my "secured" POA).

Regards
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061016/9212fbf1/attachment.htm

[Stephan February]

Post by Duncan Grisby

Post by Stephan February
- Adding an authentication token as a Service Context in a *
clientSendRequest* Interceptor.

This definitely works. I'm using it in production, and it doesn't cause
any problems.

Hello Duncan

I have hit something of a wall in the above scheme for authentication. I am
doing the following:

1) Client authenticates to server with username/password
2) Server returns a UUID as security token to client
3) Client sets UUID as token in service context for subsequent calls to
server

My problem is now how to perform step (4)

4) Server matches individual security tokens to distinct clients from
different sources

I thought to enforce (4) in the "preinvoke" method of a custom servant
manager, however I can't find a way to associate individual client requests
from different PCs with their individual "authenticated"
sessions/connections.

Any help is much appreciated.

Regards
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061020/90701a33/attachment.htm

[Duncan Grisby]

On Friday 20 October, "Stephan February" wrote:

[...]

Post by Stephan February
3) Client sets UUID as token in service context for subsequent calls to
server
My problem is now how to perform step (4)
4) Server matches individual security tokens to distinct clients from
different sources
I thought to enforce (4) in the "preinvoke" method of a custom servant
manager, however I can't find a way to associate individual client requests
from different PCs with their individual "authenticated"
sessions/connections.

Servant managers don't have access to service contexts. You have to use
a ServerReceiveRequest interceptor to get the service context. You can
then store something in per-thread state, so either your servant
manager, or the servant itself, can check the credentials of the caller.

In omniORB 4.0 you can't throw system exceptions from interceptors, but
in 4.1 you can, so if you use 4.1, you can throw CORBA::NO_PERMISSION
from your interceptor if you want.

Cheers,

Duncan.

[Sander Steffann]

Hi,

Post by Duncan Grisby
In omniORB 4.0 you can't throw system exceptions from interceptors, but
in 4.1 you can, so if you use 4.1, you can throw CORBA::NO_PERMISSION
from your interceptor if you want.

I have been throwing CORBA::NO_PERMISSION from omniORBpy interceptors
for some years, and it worked perfectly. Have I just been lucky here?

Sander

[Duncan Grisby]

Post by Sander Steffann

Post by Duncan Grisby
In omniORB 4.0 you can't throw system exceptions from interceptors,
but
in 4.1 you can, so if you use 4.1, you can throw CORBA::NO_PERMISSION
from your interceptor if you want.

I have been throwing CORBA::NO_PERMISSION from omniORBpy interceptors
for some years, and it worked perfectly. Have I just been lucky here?

Sorry, I got mixed up. In 4.0.x you _can_ send system exceptions from
interceptors. What you can't do is send user exceptions from them. You
can throw both kinds of exceptions in 4.1.x.

Cheers,

Duncan.

[Simon McQueen]

Hi Duncan,

Post by Duncan Grisby
Sorry, I got mixed up. In 4.0.x you _can_ send system exceptions from
interceptors. What you can't do is send user exceptions from them. You
can throw both kinds of exceptions in 4.1.x.

Introducing behaviour that contravenes the current CORBA spec ? What
motivated that change.

Cheers,

[Sander Steffann]

Hi,

Post by Duncan Grisby

Post by Sander Steffann

Post by Duncan Grisby
In omniORB 4.0 you can't throw system exceptions from interceptors,
but
in 4.1 you can, so if you use 4.1, you can throw CORBA::NO_PERMISSION
from your interceptor if you want.

I have been throwing CORBA::NO_PERMISSION from omniORBpy interceptors
for some years, and it worked perfectly. Have I just been lucky here?

Sorry, I got mixed up. In 4.0.x you _can_ send system exceptions from
interceptors. What you can't do is send user exceptions from them. You
can throw both kinds of exceptions in 4.1.x.

Nice to hear!

Thanks,
Sander

[Duncan Grisby]

Post by Simon McQueen

Post by Duncan Grisby
Sorry, I got mixed up. In 4.0.x you _can_ send system exceptions from
interceptors. What you can't do is send user exceptions from them. You
can throw both kinds of exceptions in 4.1.x.

Introducing behaviour that contravenes the current CORBA spec ? What
motivated that change.

omniORB's interceptors use a proprietary interface anyway, so the CORBA
spec is irrelevant here. I've encountered several situations where it
can be useful to raise user exceptions from an interceptor, to indicate
problems in service contexts.

Cheers,

Duncan.

[Simon McQueen]

Hi Duncan,

Thanks very much for the reply.

Post by Duncan Grisby

Post by Simon McQueen

Post by Duncan Grisby
Sorry, I got mixed up. In 4.0.x you _can_ send system exceptions from
interceptors. What you can't do is send user exceptions from them. You
can throw both kinds of exceptions in 4.1.x.

Introducing behaviour that contravenes the current CORBA spec ? What
motivated that change.

omniORB's interceptors use a proprietary interface anyway, so the CORBA
spec is irrelevant here.

Ah, ok. I didn't know that. Does omniORB's implementation pre-date the
portable interceptor spec or was it a conscious decision to go with an
alternate design ?

Post by Duncan Grisby
I've encountered several situations where it
can be useful to raise user exceptions from an interceptor, to indicate
problems in service contexts.

Cheers,

[Duncan Grisby]

Post by Simon McQueen
Ah, ok. I didn't know that. Does omniORB's implementation pre-date the
portable interceptor spec or was it a conscious decision to go with an
alternate design ?

The interceptor implementation is designed as an internal efficient
mechanism for use by the ORB and associated libraries. The intention is
that some day an implementation of the portable interceptors API will be
done on top of the internal API, but it hasn't been done yet.

Cheers,

Duncan.