At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C99318.3582B8D8"
Just as a matter of observation, there is not and never has been a
security requirement to rigidly separate authentication and
authorization. Indeed there is no real world deployment in which
authentication and authorization are not conflated to some degree.
Authentication and authorization (aka access control) are distinct
security services. Too often they are confused, and the result of
such confusion is never a great outcome. I have not read the doc in
question, but your dismissal of this issue is not persuasive.
The separation of authentication and authorization is a matter of
administrative and operational convenience.
nonsense. the two are implemented via a wide range of mechanisms,
many of which are independent of one another. I may use passwords or
challenge-response mechanisms or PKI technology for authentication,
and use various identity-based authorization mechanisms with any of
these means of verifying an identity. Thus there are good technical
and design reasons to consider the services and mechanisms
separately, as part of a modular design approach.
It is very rarely the case that every privilege that might
potentially be granted to a user is known in advance. Hence the
benefit of maintaining a distinction. But in practice the fact that
a party holds a valid authentication credential is in itself often
(but not always) sufficient to make an authorization decision in
low-risk situations.
True, but the fact that you had to employ several qualifiers in these
sentences to make them true illustrates the benefits of
distinguishing between the terms.
Thus an objection based on the mere risk that such a conflation may
occur is not justified as such conflation has occured in every
practical security system ever.
I don't know if the objection is an important one here, but I do
think it is important in general.
We do not issue employee authentication badges to non-employees.
Thus an employee-authentication badge will inevitably carry de-facto
authorization for any action that is permitted to every employee
(like open the office door).
A good example to make my point. It is typically the case that if
all employees have ID badges, these badges grant access to most
buildings/rooms of the employer's facilities. But many other rooms of
an employer's facilities typically are off limits to all but a few
employees.
The Authorization/Authentication model is in fact broken, in a
modern system such as SAML you actually have three classes of data
with the introduction of attributes.
SAML allows one to make security assertions of all sorts. The fact
that one can make both authentication and authorization assertions
using the same construct is distinct from the question of whether
conflating the two terms is a good idea in general, as you seem to be
arguing.
Steve
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf