[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: AuthN and Credentials - One Dissenting View
As far as I know, I'm the main dissenter on AuthN/Credentials; the one who voted that we _should_ include AuthN methods in SAML. I'll try to explain why, with liberal cut&paste from the preceding messages. Even if you skip the big hunk of exposition below, please read at least the first quote and response; I suggest new wording for the AuthN related issues. I really wish I could make it to the F2F; since I can't, I'm going to have to be quite verbose in an attempt to avoid misunderstandings. I hope that some of the people who _are_ able to attend will try to represent these issues in my absence. As I see it, AuthN comes down to: A subject asserts their "identity", and provides some reason why that assertion should be believed. This combination of "identity" and "corroborating evidence" is what _I_ mean when I say "Credentials"; others may differ. Typically, the assertion is "username = irving" and the reason is "password = whatever". In more sophisticated cases, the assertion might be "Certificate = <big ASN1 blob>" and reason is "successfully proved posession of the corresponding private key". The direction SAML seems to be going is that the only sort of credentials we support are "Identity = <arbitrary data>", "evidence = Because foo.com's security service says so". As an aside, we may attach further information so that foo.com's security service can explain _why_ they say so, but it doesn't make any fundamental difference to the validity of the credential. As far as I can see, there are two different arguments going on. Some people are talking about the structure and content of the "foo.com's security service explains _why_ they say so" mentioned in the previous paragraph. I don't see this as a big issue; we can do something like provide standard URIs for the common cases, and allow people to invent their own URIs for the cases we haven't thought of yet, and apply for standardisation of them later (sort of an IANA / clearinghouse process); there are other ways to solve the problem, and I'm sure we can pick one without serious contention. The other argument, and the one I really care about, is the argument about whether having a single sort of SAML credential, which was described in S2ML as a "Name Assertion", is sufficient. The reason I think it isn't is somewhat selfish: we perform authentication based on various sorts of credential over our PEP-PDP protocol. If SAML works out, we intend to switch over to SAML as our native PEP-PDP protocol. When we do, if SAML doesn't already support interesting forms of authentication we'll immediately need to extend it. At that point we run into all the usual problems of non-standard extensions - poor interoperation, maintenance headaches, etc. In a more philosophical sense, these Name Assertions have to come from somewhere. They could appear out of thin air, or they could be produced by a security service in response to some user input. Just for argument, I'll call the latter case a "login service". I'm specifically avoiding the term "authentication service", because to me "login" specifically implies that the _user_ is supplying the evidence. If we don't specify a login service in SAML, every one of us is going to have to go off and design our own, or convert the one we've already got so that it produces SAML name assertions. This means that customers, system integrators, application infrastructure vendors, etc. are still going to need custom code for each SAML implementation they want to support, because 99+44/100% of their applications are going to require a login service at _some_ point. Now for the specific responses to quoted text... > -----Original Message----- > From: Evan Prodromou [mailto:evan@outlook.net] > Sent: Wednesday, February 28, 2001 2:24 AM > To: 'UseCaseList ' > Subject: Re: AuthN and Credentials > > > >>>>> "MP" == Mishra, Prateek <pmishra@netegrity.com> writes: > > Me> Our high-level goal here is not to burden SAML with the actual > > MP> Agreed. This was the main point of > MP> ISSUE:[UC-5-03:AuthNThrough]; no expression of authentication > MP> within SAML > > Agreed, and it seems that the overwhelming majority of people in the > subcommittee agree (10-1!). Unfortunately, some people felt that the > wording of the non-goal was unclear or incorrect (at least that's my > guess as to why they voted against the particular non-goal). I think > that we need to find a better formulation that the dissenters could > agree to. Any dissenters have a suggestion? > > My guess is that the quibble is about "authentication." If one is > being strictly formal, I think that accepting (say) an S2ML name > assertion as proof of identity is also a form of "authentication." Is > there a clear way we can state the difference? I think we could make this clearer by presenting more than one issue. The first ones are positive requirements: [R-NameAssertion] SAML Relying Parties must be able to authenticate users based on Name Assertions. [R-NameAssertionInfo] SAML must provide a way for information about authentication to be associated with Name Assertions As for the non-goals: [NON_GOAL-LoginService] SAML will NOT specify a login service that provides Name Assertions in response to other forms of authentication. [NON_GOAL-OtherCredentials] SAML will NOT specify a way to convey credentials other than Name Assertions. As far as the actual content of Name Assertions: [ISSUE-whatever-whatever-Authn]: [R-NameAssertionInfo] requires the ability to attach additional information to Name Assertions. The envisioned application of this requirement is to include such things as "the authentication occurred at date-time X", "the authentication method was biometric toe-smell", etc. Resolutions: 1(a) SAML will define an extensible format for Name Assertions that includes additional information OR 1(b) The aforementioned additional information will be associated with Name Assertions using the oft-mentioned 'Authorization Data' SAML object, with a reference to the Name Assertion. After all, what's so different (at a strict data representation level, rather than semantically) about saying "The subject of <NameAssertion> is a member of group 'Administrators'" or "The subject of <NameAssertion> authenticated using the method identified as URI://saml.oasis.org/Toe-Smell"? Independent of the choice of 1(a) or 1(b), the second issue is whether to provide a standard (and extensible) way of describing the authentication method; I think there are existing Issues that cover this question. > -----Original Message----- > From: Mishra, Prateek [mailto:pmishra@netegrity.com] > Sent: Tuesday, February 27, 2001 6:33 PM > To: 'Orchard, David'; UseCaseList > Cc: Ahmed, Zahid > Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario > Variations > > > David, > > if we exclude credentials from SAML we are going to be left > with very little in the way of identifying subjects. What is > the point of a name assertion if we do not have standard ways > of calling out "names" within it: public keys, string tokens, > X509 DNs, > Certificates, and yes, even name and password (just another > secret credential). How can we have an interesting notion of > an Az service > if there > are no standard credentials? > > > > > I believe this was voted out of scope for SAML version 1.0, > > I have no reason to believe we have agreed not to standardize > credentials. It remains on the issue list (I believe with > an 8Yes/ 3No vote) and remains very much part of our > discussion. I think this really ties back to the re-wording I suggested above. I suspect that the 10-1 vote was really a vote against specifying a Login Service. I would be surprised if anyone suggested that we shouldn't support "authentication" of Name Assertions, where "authentication" means checking their structural validity by verifying signatures or such like, deciding whether to believe the Name Assertion based on the identity of the Asserting Party, and deciding what authorization response is appropriate based on the identity (or anonymity) of the subject, the identity of the Asserting Party, and the associated information related to the Name Assertion (such as AuthZ Attributes or descriptions of authentication methods). That said, the authentication I describe above really isn't any of SAML's business. As long as we specify the _format_ of the Name Assertion, the Relying Party is free to interpret the content however they choose. They probably won't get many customers if their interpretation is silly, but that's their problem. Hmm. I just thought of another possibility - Are there people who interpreted the "Authentication Service" question as meaning a service that, given a Name Assertion, returns an opinion as to the validity of the Name Assertion? In that case, I can see why we're debating. 'validity' of a name assertion, aside from at the lowest level of signature verification, is entirely application-specific. I suspect that what Prateek means when he says "standardise credentials" is _not_ "standardise how SAML implementations are required to assign trust to credentials", but rather "standardise how to describe what sort of credentials were presented". The second form is necessary in order to make policy decisions such as "Allow <subject> to <verb> <object> only if they logged in using an X9.9 Challenge-Response."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC