>You are also right in noting that specifying trust anchors does not in
itself constitute a complete
>authentication policy-- it is at best a component of the authentication
policy.
>Explicit checks on the DN, issuer serial number, etc might be used to check
identity.
>And identity might be variably mapped (ACLs) to resources depending on
service,
>action, role, and other parameters. Those more elaborate authorization
issues are not things
>treated in the current maintenance version.
I'm concerned Transport Security Policy is including informatioon about
Trusted CA
issuers (as part of TrustedAnchors) and not TrustedClients, which means that
transport
security information is incomplete w.r.t. capturing of relevant
authentication policy
information. In the specific example of SSL mutual authentication (for which
the CPA/CPP
spec has included relevant TransportClientSecurity and
TransportServerSecurity
components) between 2 colloborating parties' MSHs if we will exploit from
the CPA/CPP's
TrustAnchor, i.e., Trusted CA Roots information, then we should also be able
to
maintain TrustedClient or TrustedDomains information.
In my original suggestion of including TrustedClient information in the
SecurityDetails
element:
<element name="SecurityDetails">
<complexType>
<sequence>
<element ref="tns:TrustAnchors"
minOccurs="0" maxOccurs="unbounded"/>>
<element ref="tns:TrustedClients"
minOccurs="0" maxOccurs="unbounded"/>>
<element ref="tns:SecurityPolicy"
minOccurs="0" maxOccurs=unbounded"/>>
<any namespace="##other"
processContents="lax" minOccurs=unbounded"/>>
</sequence>
<attribute name="securityId" type="ID"
use="required"/>
</complexType>
</element>
<element name="TrustClients">
<complexType>
<sequence>
<element name="TrustedClientCertificateRef"
type="tns:CertificateRef.type" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
the intention is that we validate the incoming client cert chain using
TrustedAnchors and
then validate that incoming client is trusted using the TrustedClients or
TrustedDomains
of the receiver. This is a simple DN level authorization. If we decide not
to include any
TrustedClient element in the SecurityDetails, i.e., such trust policy info
will not be available in
the CPA, then we will need to atleast point that out that as a system
configuration step of
the receiving MSH such authentenctication policies will need to be enforeced
via local
adminsteration of the transport system, e.g., web server. TrustedClient or
TrustedDomain
scope could be applicable to botuh Transport and Message level security.
E.g.,
some discussion needs to be added to Sections 1.2.3 (Opperational Policies
and
Constraints) and/or 4.1.4.8 (Non-Persistent Authorization).
>We are waiting to review specs of other groups before taking on
authentication or authorization.
>Agreements on credentials for username/password tokens will need to use
>encryption, for example, so we are waiting on xml encryption being
available.
>The SAML and XACML groups may eventually produce specs usable for
>some security policy expressions. So we are in a way avoiding getting into
too much
>detail here while some other supporting specs get finished.
I'm particpating SAML group which definitely needs to be applied to ebXML
messaging.
I believe we have had some discussions about this before in this group.
However, I think we should separate out the layers of authentication events
and
include a general section in the ebXML Messaging specification that spells
out
the Authentication Mode for Messge Exchanges. For example, I propose
addition in the ebXML Messaging spec something along the following:
=============================================================
ebXML Authenticated Message Exchange Model
ebXML Messaging system supports:
1) Transport-level authentication (e.g., SSL mutual authentication for HTTPS
transport option)
2) Message-level authentication
3) Document-level authentication
SSL certificate based mutual authentication is applicable to transport level
security (e.g.,
over HTTPS) to verify trustworthy connection sessions between ebXML
parties's sending and receiving
transprot systems (MSHs), for example over the HTTPS protocol.
Digital Signature over the ebXML message and/or explicit application of SAML
based
Credential is applicable to the message level security in support of
authentication
of message originating party. Both of these may be used independent of
transport security
and can provide application level authorizations.
Document-level authentication provides capabilities to verify the identities
of document
originators, which may or may not be the same principals as message
originators.
===============================================================
Obviously, the lack of a concrete transport independent authentication and
authorization scheme being employed in ebXML seems to be the root problem
here.
---Zahid