| Summary: | User not able to specify no authentication on a per object basis. | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Tom Venturella <venturella_t> |
| Component: | SSLIOP Pluggable Protocol | Assignee: | cleeland |
| Status: | ASSIGNED --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.2.1 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Tom Venturella
2002-02-27 16:59:51 CST
I guess that this is mine. Steve, can this be rechecked by OCI, the report is about 1.2.1 which is ancient Chris, when you have a chance, would you confirm whether or not this problem has been fixed? If this hasn't been fixed, can then a regression be delivered? That way it is much easier to see that this is broken, and when someone has time to work on the fix, we can clearly see if things are working again I will simply have to take some guesses as to what the original report means. At first glance, it appears that this might mean that, if SERVER_AND_CLIENT is specified as the SSL authentication method, then there is some kind of failure if one tries to perform a set_policy_overrides() on the Quality of Protection for an individual Object Reference I will try to look at it in my spare time and either come up with a variant of an existing test or a completely new test. Spent a little more time looking at this and discussing, and the original report is ambiguous as to whether it's talking about the problem occurring from the server or from the client's perspective (or both). It looks like what it wants is to be able to have SERVER_AND_CLIENT specified in the .conf, but then be able to get the equivalent of authenticate=NONE on a per-object basis. Authentication is different from QoP, so I think we're talking about tweaking policies related to the Security::EstablishTrust policy. It doesn't look like there's a test for this in the DOC repo, although there is an example created for the TAO Developer's Guide: Security/PolicyControllingApp. We might be able to massage that example into a test. The only problem I can foresee is that a lot of the SecurityLevel1 and SecurityLevel2 code has been foresaken in favor of SecurityLevel3. But, the SecurityLevel3 implementation isn't as complete as the SecurityLevel1/2 code was. It will take some time to figure out what to do, exactly. |