${taskforce.name} Avatar
  1. OMG Task Force

Security 1.5 RTF — All Issues

  • Key: SEC15
  • Issues Count: 15
Open Closed All
All Issues

Issues Descriptions

Does AuditPolicy use an implicit ALL combinator?

  • Key: SEC15-13
  • Legacy Issue Number: 378
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: AuditPolicy audit_needed only returns OK if selector values passed in match All. the values set in policy. Doesn"t have ANY/ALL combinator flexibility of RequiredRights. Too rigid?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

When is the "ObjectRef" selector type used?

  • Key: SEC15-14
  • Legacy Issue Number: 379
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.6.1: Object selector type isn"t something that would be stored in policy. It would be better to have Object as a seperate argument rather than to call it a selector type.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    same as issue 360, close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RequiredRights

  • Key: SEC15-15
  • Legacy Issue Number: 716
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: get_required_rights takes target objref as argument. The set_required_rights takes no such argument. Does spec address the correlation of required_rights to actual targets?

  • Reported: SEC 1.1 — Thu, 28 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    same as issue359, close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance not properly accounted in audit operation parameters

  • Key: SEC15-11
  • Legacy Issue Number: 360
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I do not think inheritance has been acounted for properly in the audit operation parameters.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Which interface apply RequiredRights to

  • Key: SEC15-10
  • Legacy Issue Number: 359
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify which interface the RequiredRights apply to in a chain of derived interfaces. I missed that RequiredRights can be changed dynamically

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    clarify specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QOP discovered in SecurityContext

  • Key: SEC15-9
  • Legacy Issue Number: 347
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: SecurityContext::reclaim_message uses length of supplied token as IMPLICIT parameterindicating QOP which was applied to the supplied message. Carried differently in SECIOP protocol.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Security RTF 1.5 action 9 in ptc/98-11-02

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_security_names issue

  • Key: SEC15-8
  • Legacy Issue Number: 341
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: get_security_names should be able to return the mutually authenticated "identity" (??) of an object. It should have option indicating whether caller wants all supported security names.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Security RTF 1.5 action 1 in ptc/98-11-02

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why do DomainAccessPolicy set methods have family arguments?

  • Key: SEC15-12
  • Legacy Issue Number: 373
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Set methods of DAP have ExtensibleFamily and Rightslist arguments. Rights datacontains family values already? Description on p150/151 doesn"t mention rights_family arguments.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_security_names

  • Key: SEC15-2
  • Legacy Issue Number: 2094
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: e have a SecurityMechandNameList get_security_names(in Object objref);
    on SecurityLevel2::Current.

    Since we have this capability, we should have a similar way of getting the
    mechanisms and options.

    Unfortunately, Security::MechandOptions struct only contains options
    supported and does not have options required. The only place it is used is
    for Vault::get_supported_mechs();

    We should probably have another structure to handle the mechs on the
    object reference. We will call this the mechanism data as not to confuse
    it with MechandOptions struct.

  • Reported: SEC 1.4 — Fri, 16 Oct 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    :Current.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PrincipalAuthenticator and Current

  • Key: SEC15-1
  • Legacy Issue Number: 2027
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I have a problem discovering the semantics of using
    Current.set_credentials(SecInvocationCredentials) as opposed to using an
    InvocationCredentials Policy object on Current, or the target object
    reference.

    I believe we should deprecate set_credentials and get_credentials infavor
    of InvocationCredentials and NonRepudiationCredentials Policy Objects.
    This mechanism seems more in line with the the way we seem to be
    traveling. So it will be consistent with the client invocation policy
    model.

    Or. we should put an explicit statement ordering the retrieval of
    credentials at object reference creation.

    1. InvocationCredentailsPolicy object off of Target object reference.
    2. InvocationCredentialsPolicy object from the Current.
    3. Current.get_credentials()

  • Reported: SEC 1.4 — Fri, 2 Oct 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Close issue 2027: Principal Authenticator and Current

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 15-25 Attribute Values lists family 0 attributes as family 1

  • Key: SEC15-7
  • Legacy Issue Number: 2199
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think its a formatting problem rather than a type-o. The "Privilege
    Attribute (family = 1)" heading looks like it was automagically copied
    to the first row of the table when the table cross a page break.

  • Reported: SEC 1.4 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Close issue 2199. Table 15-25 Attribute Values lists family

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityAdmin::DomainAccessPolicy::grant_rights takes SecAttribute

  • Key: SEC15-6
  • Legacy Issue Number: 2170
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 15-140 of security/98-10-01, the description of grant_rights
    says the first parameter is Attribute. The first parameter should be
    SecAttribute.

  • Reported: SEC 1.4 — Thu, 5 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Close issue 2170.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table description incorrect in Security Service

  • Key: SEC15-5
  • Legacy Issue Number: 2169
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Table 15-7 has the title "Domain Access Policy (with Required Rights
    Mapping)". The "(with Required Rights Mapping)" part should be
    removed since it doesn"t include the required rights.

  • Reported: SEC 1.4 — Thu, 5 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Close issue 2169. Table description incorrect

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityLevel2::Current policy factory operation

  • Key: SEC15-4
  • Legacy Issue Number: 2161
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The Policy factory operations in SecurityLevel2::Current should be
    deprecated and the ORB::create_policy operation should be used for
    creating QOPPolicy, MechanismsPolicy, InvocationCredentialsPolicy
    instead.

  • Reported: SEC 1.4 — Tue, 3 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    :Current should be

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in 15.7.1.1, p.15-145, very last bullet:

  • Key: SEC15-3
  • Legacy Issue Number: 2122
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In 15.7.1.1, p.15-145, very last bullet:
    SecureInvocationPolicy::get_delegation_mode should be
    DelegationPolicy::get_delegation_mode.

  • Reported: SEC 1.4 — Tue, 27 Oct 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    :get_delegation_mode should be

  • Updated: Fri, 6 Mar 2015 20:58 GMT