| Summary: | SSLIOP_Acceptor incorrectly uses the same SSL component for all objects | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Ossama Othman <ossama.othman> |
| Component: | SSLIOP Pluggable Protocol | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.1.9 | ||
| Hardware: | All | ||
| OS: | All | ||
I'll get to this in a couple of weeks. The IORInterceptor and PolicyFactory interfaces defined in the Portable Interceptor specification provide the functionality necessary to implement per-object security association options. More notes... IORInterceptors and PolicyFactory registration have been implemented. However, the SecurityLevel2::SecurityManager appears to be the solution to this problem. I'll probably implement its get_security_policy() method (and just that method) for TAO 1.1.12. |
The SSLIOP_Acceptor currently uses the same SSL component for each endpoint. This forces all endpoints created in the given ORB to each have the same required and supported security association options (SSLIOP::SSL::target_{requires, supports}). This level of granularity (endpoint granularity) is too coarse grained. An object level granularity must be implemented instead. The SSL port of course remains the same for the life of the endpoint, and subsequently in the IORs generated for each object by the given SSLIOP_Acceptor. Potential changes may include updates to SSLIOP_Acceptor::create_mprofile(). The ORB/object will have to be queried for the security policies associated with the object whose MProfile is being created and set the appropriate security association bits in the SSLIOP::SSL component for the given object. Since not all objects will require secure invocations, the standard insecure port must remain open for the life of the ORB. Access to the object should not be regulated by shutting down the insecure port since other objects that do not require secure invocation may be using the same endpoint.