[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FYI (old msg for the record): [security-services] First draft of aSAML FAQ
-------- Original Message -------- Subject: [security-services] First draft of a SAML FAQ Date: Fri, 30 Nov 2001 18:31:22 -0500 From: Eve L. Maler <eve.maler@sun.com> To: security-services@lists.oasis-open.org The questions are all real ones I've gotten (or asked myself). The answers that appear so far are from Hal, lightly edited by me. If you want to take a crack at an answer, just send it to the list and I'll incorporate it. Eventually, I'll make this a lot prettier. EveTitle: SAML FAQ - 29 November 2001 draft
29 November 2001 draft
This FAQ helps to answer frequently asked questions about SAML, the Security Assertion Markup Language. If you have a question that is not answered here, or if you have questions or comments on one of the answers provided, let us know.
Any entity that can authenticate another entity (verify identity) can potentially act as an Authentication Authority and issue a SAML authentication assertion. It is up to relying parties, for example a PDP, to decide what Authentication Authorities it chooses to trust.
The means of ensuring
that the entity making a request and the entity referred to by an assertion
are one and the same is dependent on the environment and protocols being used.
The general mechanism provided is the SubjectConfirmation
element,
which is intended to carry data appropriate to the environment. Possible mechanisms
include an artifact encoded in a URL, a Kerberos service ticket, or a public
key associated with signature on a document. SAML profiles will specify the
details for different situations.
It is expected that others besides the SAML Technical Committee will define other schemes appropriate for other enviroments. They might or might not publish these as profiles, but doing so ensures greater interoperability.
SAML doesn't really do anything "in general". Profiles are expected to prevent or minimize MITM attacks as much as possible given the limitations of the environment in question. The Security and Privacy Considerations document discusses (will discuss?) what should be considered.
TBD
TBD
SAML is a very general framework which will be used in a wide variety of environments. It is up to relying parties to decide what Asserting Parties they trust for what purposes. For example, Company A might trust Company B to tell it if an individual was a Company B employee, but not to tell if the employee has a Secret Clearance.
TBD
Any PDP will have a policies covering a finite number of resources.
If it is asked about a resource for which it has no policies, it will produce
an "Indeterminate
" response. It is up to the PEP to locate a
PDP that knows about the resources it protects. SAML does not provide any
automated way of doing this.
Trust relationships must be established out of band. Also a certain amount of configuration information, for example network addresses, will have to be exchanged out of band.
You are allowed to use SAML requests and responses over any protocol you like. Whether you will be able to interoperate with anybody else is another question. The SOAP-over-HTTP protocol is intended to be very simple to implement and should represent less work than implementing SAML requests and interpreting SAML responses.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]