Defining Trust
The casual use of trust creates
challenges of understanding when trying to create a federated environment. For the purpose of this document it is
necessary to strictly define trust. Trust is a mutual understanding consisting of
three parts:
1.
A defined and scoped behavior that is mutually
understood and measurable,
2.
A means by which both parties can verify the
performance of the behavior, and
3.
Defined consequences for the familiar to perform
the behavior in accordance with the previously established metrics.
These simple parameters define how
organizations can establish relationships that enable the transfer of identity
information in full confidence that the identity presented has been adequately
vetted and authenticated. The word
“adequate” is used to indicate that the presented information is within the
bounds of the established trust.
Depending upon the trust, and the requirements of the relying party,
“adequate” may vary from trust agreement to trust agreement. Each trust agreement, therefore, establishes
a baseline.
The Trust Agreement
The trust agreement is a legal
document outlining the terms and conditions by which both parties to the trust
are bound. Generally, these terms
include the defined baseline for vetting users, conditions for the users’ removal
from the environment, and the methods by which a user can authenticate. All of these, and any other elements that are
included, are assigned metrics that are reported to all parties on a pre-determined
interval for review. Spot checking is
also included (if desired) in the trust agreement. If the metrics are not met, the negative
consequences are enacted. These may
include loss of access, diminished functionality, and/or financial penalties
that have been agreed to in the trust.
The trust may also include positive consequences for exceeding the
assigned metrics.
Technical Trust
Once the legal trust is
established, it is necessary to technically enforce the agreements, and provide
both verification and non-repudiation of access. This is done via the technical mechanism of
digital certificate exchange. The parties in the trust exchange certificates
and the SAML[1]
requests are all signed from the identity provider to the service provider, and
then returned to the service provider signed with the service provider’s
key. This provides a bidirectional basis
of trust for the transfer of the identity information. Please note that each identity assertion is
signed, not just the “tunnel”. An
example of the flow of data from the initial access request to the return of
the authorized resource is found in Figure 1.
Figure 1 : Example of a TLS secured SAML
authentication request
Conformance
To adequately conform to the
technical trust, both the service and identity provider must be able to
properly present and accept signed assertions, and be able to decrypt them in
adherence to the X.509[2]
standard for digital certificates. Both parties must also agree to, and comply
with, the configuration of optional meta-data elements of the SAML
assertion.
What the Trust Does Not Cover
One of the defining purposes of the
trust is to create clear delineation between the responsibilities of the
identity provider and the service provider.
The authorization of identified individuals to resources of the service
provider is solely the service provider’s responsibility. The provisioning of identity, the issuance of
credentials and the identity lifecycle of individuals is solely the
responsibility of the identity provider.
The only contact of these items for both providers with the trust is in
meeting the established metrics.
Dissolution or Revision of the Trust
Should circumstances require that
the trust be dissolved or revised, the technical elements of the trust must be
revised and tested in advance to enable a smooth transition to the new
trust. Under no circumstances should
there be more than one trust agreement in place for a single technical
connection.
[1]
All references to SAML refer to SAML 2.0 as defined in http://docs.oasis-open.org/security/saml/v2.0/
[2] Defined in RFC 4158
No comments:
Post a Comment