Security Service Avatar
  1. OMG Specification

Security Service — All Issues

  • Acronym: SEC
  • Issues Count: 12
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

SecurityContext::process_context_token

  • Key: SEC18-5
  • Legacy Issue Number: 3572
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The GSS-API calls for a process_context_token function to process
    context tokens. There is no such operation on the SecurityContext
    interface.

  • Reported: SEC 1.7 — Wed, 19 Apr 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    Apply revisions and close issue.

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

AuditChannel::audit_write has Opaque

  • Key: SEC18-4
  • Legacy Issue Number: 3571
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Summary:
    The audit_write operation on AuditChannel still has an Opaque
    type for event_specific_data. RTF 1.7 changed a bunch of these
    Opaques to "any", and this one got missed. Its type needs to be
    changed to "any".

  • Reported: SEC 1.7 — Wed, 19 Apr 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close with revised text

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

CCM spec and Security Service 1.7 do not agree

  • Key: SEC18-10
  • Legacy Issue Number: 3630
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM spec changed some of the interfaces in the Security Service to
    local ones. However, apparenlty some interfaces were not made local
    that should be made local, if understand things correctly. Here are
    suggested changes:

    1. The SecurityLevel2::TargetCredentials interface is derived
    from the Credentials object, which the CCM spec made
    local. This means that the TargetCredentials interface
    must also be declared local.

    2. The SecurityLevel2::SecurityManager interface is apparently
    locality constrained (please improve/add comment), but the
    CCM spec does not change its interface to be local. This
    is a problem since the
    SecurityManager::remove_own_credentials() method takes a
    "in Credentials creds" parameter, i.e.:

    void remove_own_credentials(
    in Credentials creds
    );

    but the CCM spec changes the Credentials interface to be
    local. As such, the SecurityLevel2::SecurityManager
    interface should also be local in the CCM spec in order for
    the above method to be valid.

  • Reported: SEC 1.7 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    No Data Available

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

editorial revisions to address issue #1765 were not completed correctly

  • Key: SEC18-3
  • Legacy Issue Number: 3442
  • Status: closed  
  • Source: ( Luis Maldonado)
  • Summary:

    The editorial revisions which were to address issue #1765 were not completed correctly. In section 15.5.4, the text for the parameter section of the newly added set_attributes operation still contains references to the parameters of the previous set_privileges operation. Text for the 1st, 2nd and 3rd parameters (force_commit, requested_priveleges and actual_privileges) should be removed. Also, the last parameter (actual_priveleges) should be renamed actual_attributes.

  • Reported: SEC 1.7 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    closed with revised text

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

Fix description of parameters to Credentials::set_attributes

  • Key: SEC18-11
  • Legacy Issue Number: 3638
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    On p.98 of 99-12-02, in the change to Credentials::set_privileges, the
    text of the parameter descriptions did not get updated. It still
    contains force_commit, requested_privileges, actual_privileges, etc.

  • Reported: SEC 1.7 — Mon, 22 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close, same as Issue 3442

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

URL format for IIOP-SSL

  • Key: SEC18-7
  • Legacy Issue Number: 3591
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    The definition of the syntax for IIOP over SSL is missing in the
    corbaloc URL definition.

    I would propose to name the protocol 'iiops'.
    The protocol token would then be the same as for 'iiop'.
    Is there a need to extend it with fields for 'target_supports' and
    'target_requires'?

  • Reported: SEC 1.7 — Tue, 2 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close without action

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

Differ by case IDL error in "Right" structure Security module

  • Key: SEC18-8
  • Legacy Issue Number: 3620
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Security Service 1.7 specification:

    http://www.omg.org/cgi-bin/doc?security/1999-12-02.pdf

    has a "differ by case" error in the Security module IDL:

    // Declarations related to Rights

    struct Right

    { ExtensibleFamily rights_family; string right; }

    ;

    The name of the structure "Right" and one of it members "right" only
    differ by case which of course isn't allowed in CORBA IDL.

    I also checked the RTF Final Report for the 1.7 spec, and didn't
    notice any resolution to this problem.

  • Reported: SEC 1.7 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    Apply revision and close issue.

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

Inconsistency in security service spec

  • Key: SEC18-12
  • Legacy Issue Number: 3765
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I've found an inconsistency in an OMG spec. We've implemented a part of
    CORBAsecurity and are now switching to a new version of Visibroker (4.0). This
    version supports new OMG standards, among those some changes to IDL syntax
    (e.g., case-insensitivity and keywords).

    Now, there's a conflict between the CORBA 2.3 spec (3.2.3 Identifiers):

    > "When comparing two identifiers to see if they collide:
    > - Upper- and lower-case letters are treated as the same letter.

    and the CORBAsecurity spec, even the newest version 1.5 (00-06-25):

    > module Security {
    > struct Right

    { > ExtensibleFamily rights_family; > string right; > }

    ;
    > }

    It is not possible to compile this spec because of "right" in
    "::Security::Right" !!!!!!!
    I assume this is a general conflict between old and new specifications.

    What should we do in order to keep compatible? Will the Security Service spec be
    changed?

  • Reported: SEC 1.7 — Fri, 21 Jul 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    Same as issue 3620. Classify as duplicate.

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

No Standard Authentication Mechanism Specification for Kerberos

  • Key: SEC18-6
  • Legacy Issue Number: 3577
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    There is no standard specification for the process of authenticating a
    Kerberos principal in the PrincipalAuthenticator::authenticate call. We
    need specifications of authentication method constants, and a
    specification for the combined authetication_method, security_name,
    authentication_data, and continuation_data parameters of the authenticate
    call.

  • Reported: SEC 1.7 — Tue, 25 Apr 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    No Change and close issue.

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

SecurityReplaceable module errors in Security spec 1.7

  • Key: SEC18-9
  • Legacy Issue Number: 3629
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are a few errors in the IDL listed in the Security Service 1.7
    spec in the SecurityReplaceable module. They are:

    1. In the Vault interface:

    Security::AuthenticationMethodList
    get_supported_authen_methods(
    in Security::MechanismType mechanism;
    );

    There is an extraneous semi-colon after the MechanismType
    parameter. This should be:

    Security::AuthenticationMethodList
    get_supported_authen_methods(
    in Security::MechanismType mechanism
    );

    2. In the SecurityContext interface:

    boolean process_discard_token (
    in Security::OpaqueBuffer discard_token,
    );

    There is an extraneous comma after the OpaqueBuffer parameter. This
    should be:

    boolean process_discard_token (
    in Security::OpaqueBuffer discard_token
    );

  • Reported: SEC 1.7 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close with revised text

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

SECIOP Sequencing Layer is superfluous and redundant

  • Key: SEC18-2
  • Legacy Issue Number: 3272
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Security RTF 1.2 introduced (incorrectly) a data link seqencing protocol
    into SECIOP. Since SECIOP is a transport protocol, meaning that it is
    required to be handled over a reliable transport. The Sequencing layer was
    introduced because of a missunderstaning of GIOP fragmentation, message
    ordering, and the GIOP connection.

    Solution: Propose to remove the SECIOP sequencing layer and references to
    it.

  • Reported: SEC 1.7 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    closed with revised text

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

Regarding Principal Authenticator in security/99-12-02

  • Key: SEC18-1
  • Legacy Issue Number: 3262
  • Status: closed  
  • Source: Hewlett-Packard ( Jan Pachl)
  • Summary:

    As I recall, two operations from Principal Authenticator were added to
    the Vault interface at one point a year or so ago, with the idea that the
    Principal Authenticator would simply pass those calls through to Vault,
    rather than implementing them directly. But paragraph [971] still says
    that Principal Authenticator may be used by Vault. It's now the other way
    round: P.A. uses Vault.

    In fact, is Principal Authenticator still one of the replaceable
    objects? Since P.A. uses Vault to do its work, it should be enough to
    make Vault replaceable. It still says in paragraphs [874], [974] and
    [1704] that P.A. is replaceable.

  • Reported: SEC 1.7 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close with revised text

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