10:58 a.m.
On Jan 11, 2009, at 10:07 AM, Emmanuel Dreyfus wrote:
Hello
I am not sure this is the right place for that question, but I cannot
figure a better one. Please point me to the right place if there is a
better one than here.
[[from openldap-software]]
I know how to use x509 certificate to authenticate a client against
OpenLDAP. It works great with ldap{search|add|modify|delete|
whatever}.`
Now I would like to do the same with the client being a web browser
and
with a web application between the browser and slapd:
browser (client cert) --> apache (PHP web application) --> slapd
Client certificate authentication from the browser to apache is
strightforward.
Yes, so why complicate it?
Therefore I can easily have the client authenticating to the web
application, and the web application operating on the directory on
behalf on the client (the web app should bind to the directory as a
privilegied user that would have authzTo: *)
The web application should just authenticate as itself and then use
proxy authorization to act on behalf of the client.
Of course, it has to be authorized to do so.
But it would be nicer to actually have the client authenticate to
slapd
using its own client certificate.
Why? Generally, the web application is part of the service which
encompasses the web server and directory service. They should already
have an appropriate trust relationship.
That is, having the web application
behaving as a kind of proxy, without any special privilege on the
directory. Is that possible? If it is, where should I start?
Would require cooperation between the web server and the directory
server. So nothing gained, IMO, except complexity.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
11:22 a.m.
New subject: web apps and client certificate authentication
Kurt Zeilenga <Kurt(a)OpenLDAP.org> wrote:
Why? Generally, the web application is part of the service which
encompasses the web server and directory service. They should already
have an appropriate trust relationship.
When using plain password authentication, the web app can just hands the
DN and password to slapd, it does not need any special privilege.
If the web app is entrusted with an authzTo: *, then a bug in it could
be used to get full directory access.
> That is, having the web application
> behaving as a kind of proxy, without any special privilege on the
> directory. Is that possible? If it is, where should I start?
Would require cooperation between the web server and the directory
server. So nothing gained, IMO, except complexity.
This would be complexity in an unprivilegied piece of code, rather than
giving trust to an application. Both approaches have merits. In order to
really compare them, one need an idea of the complexity.
How would one implement that kind of "proxy certificate authentication"?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
4:20 p.m.
New subject: web apps and client certificate authentication
On Jan 11, 2009, at 11:22 AM, Emmanuel Dreyfus wrote:
Kurt Zeilenga <Kurt(a)OpenLDAP.org> wrote:
> Why? Generally, the web application is part of the service which
> encompasses the web server and directory service. They should
> already
> have an appropriate trust relationship.
When using plain password authentication, the web app can just hands
the
DN and password to slapd, it does not need any special privilege.
But a bug in the web app could not only give access the directory for
all subsequent users of the web app, but also to other information/
services protected by the user and password information available via
that web application.
If the web app is entrusted with an authzTo: *, then a bug in it could
be used to get full directory access.
>> That is, having the web application
>> behaving as a kind of proxy, without any special privilege on the
>> directory. Is that possible? If it is, where should I start?
> Would require cooperation between the web server and the directory
> server. So nothing gained, IMO, except complexity.
This would be complexity in an unprivilegied piece of code, rather
than
giving trust to an application.
Not necessarily. The level of cooperation necessary, I believe, is so
that the web app would have to be "trusted". And that's no better
than the proxy authzid use case.
Both approaches have merits. In order to
really compare them, one need an idea of the complexity.
How would one implement that kind of "proxy certificate
authentication"?
I leave this as an exercise to someone who strong knowledge of TLS and
its certificate-based authentication. I'm only saying it that it's
likely possible, at least, in theory. I don't think it's practical.
-- Kurt
5:14 a.m.
New subject: web apps and client certificate authentication
Kurt Zeilenga wrote:
On Jan 11, 2009, at 11:22 AM, Emmanuel Dreyfus wrote:
> Kurt Zeilenga <Kurt(a)OpenLDAP.org> wrote:
>
>> Why? Generally, the web application is part of the service which
>> encompasses the web server and directory service. They should already
>> have an appropriate trust relationship.
>
> When using plain password authentication, the web app can just hands the
> DN and password to slapd, it does not need any special privilege.
But a bug in the web app could not only give access the directory for
all subsequent users of the web app, but also to other
information/services protected by the user and password information
available via that web application.
I thought a lot about the risks introduced by a web-based LDAP
application. If a web application does not store user and password
information because it keeps LDAP connections persistent in a web
session then the risk is significantly lower than having a long-term
service credential with a lot of power. (You might already have guessed
web2ldap does it like this ;-)
>>> That is, having the web application
>>> behaving as a kind of proxy, without any special privilege on the
>>> directory. Is that possible? If it is, where should I start?
>> Would require cooperation between the web server and the directory
>> server. So nothing gained, IMO, except complexity.
>
> This would be complexity in an unprivilegied piece of code, rather than
> giving trust to an application.
Not necessarily. The level of cooperation necessary, I believe, is so
that the web app would have to be "trusted". And that's no better than
the proxy authzid use case.
Kurt, one has to specify in detail "trusted for what". IMO proxy
authorization is much more powerful than e.g. HTTP authentication with
SPNEGO/Kerberos with the service being trusted to receive forwardable
tickets (TGTs).
> Both approaches have merits. In order to
> really compare them, one need an idea of the complexity.
>
> How would one implement that kind of "proxy certificate authentication"?
I leave this as an exercise to someone who strong knowledge of TLS and
its certificate-based authentication. I'm only saying it that it's
likely possible, at least, in theory. I don't think it's practical.
I don't know of any existing mechanism one could use. Maybe a
challenge-response SASL mech which uses Javascript signing at the
client's side.
Ciao, Michael.
6:04 a.m.
New subject: web apps and client certificate authentication
Kurt Zeilenga <Kurt(a)OpenLDAP.org> wrote:
I leave this as an exercise to someone who strong knowledge of TLS
and
its certificate-based authentication. I'm only saying it that it's
likely possible, at least, in theory.
I thought a bit about it, here is my conclusions. Please tell me if I am
wrong.
There is no way for a web app, (for instance written in PHP) to perform
an SSL handshake with the browser. Apache does it, all it can do is to
hand the client credentials to the web app, which executes after the SSL
handshake took place.
I see a solution, though. When doing HTTP authentication using LDAP,
Apache performs a ldap_bind using credentials given by the client. For
now the LDAP handle obtained from ldap_bind is just forgotten. Apache
could keep it and make it available to other modules (like mod_php) for
them to perform LDAP operations on behalf of the client.
That would require 3 modifications
1) implement x509 certificate authentication in Apache runtime library
(it only does ldap_bind_s using login/password for now)
2) save the LDAP handle somewhere
3) add a ldap_bind_preauth() function in mod_php so that PHP code can
get the LDAP handle
There is something not very clear in my mind about how the LDAP handle
can be sent from Apache to mod_php. Everything happens in the same
process, so I guess an environement variable containing the address of
the LDAP handle would do the trick, but is that reasonable?
Opinions? Is that plan pure science fiction, or is there something to
experiment here?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
9:33 a.m.
New subject: web apps and client certificate authentication
Emmanuel Dreyfus wrote:
There is no way for a web app, (for instance written in PHP) to
perform
an SSL handshake with the browser. Apache does it, all it can do is to
hand the client credentials to the web app, which executes after the SSL
handshake took place.
Yes. However in theory the web app could run within a custom HTTP server
and intercept the SSL/TLS handshake.
I see a solution, though. When doing HTTP authentication using LDAP,
Apache performs a ldap_bind using credentials given by the client.
Are you talking about HTTP basic authentication. Yes, then the web
server gets the clear-text password and the web app can access it too.
For
now the LDAP handle obtained from ldap_bind is just forgotten. Apache
could keep it and make it available to other modules (like mod_php) for
them to perform LDAP operations on behalf of the client.
With HTTP basic authc you can get the clear-text password from env var
REMOTE_PASSWORD. But you will not gain anything and it's better to
implement form based password input since the browser caches the HTTP
basic authc credentials.
That would require 3 modifications
1) implement x509 certificate authentication in Apache runtime library
(it only does ldap_bind_s using login/password for now)
2) save the LDAP handle somewhere
3) add a ldap_bind_preauth() function in mod_php so that PHP code can
get the LDAP handle
I don't fully understand your approach. How is the LDAP bind supposed to
work end-to-end with your approach?
Ciao, Michael.
1:46 p.m.
New subject: web apps and client certificate authentication
Michael Ströder <michael(a)stroeder.com> wrote:
Yes. However in theory the web app could run within a custom HTTP
server
and intercept the SSL/TLS handshake.
In fact I thought a bit more about it and I do not think it can work: if
the HTTP server intercepts the SSL handshake and proxy it to slapd, then
the SSL connexion will be between the web browser and slapd. The HTTP
server will not be able to handle the request.
In fact we would need a double SSL handshake: one with the HTTP server
and another one with slapd, proxyied by the HTTP server. I am not even
sure it is possible.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
4 p.m.
New subject: web apps and client certificate authentication
Emmanuel Dreyfus wrote:
Michael Ströder<michael(a)stroeder.com> wrote:
> Yes. However in theory the web app could run within a custom HTTP server
> and intercept the SSL/TLS handshake.
In fact I thought a bit more about it and I do not think it can work: if
the HTTP server intercepts the SSL handshake and proxy it to slapd, then
the SSL connexion will be between the web browser and slapd. The HTTP
server will not be able to handle the request.
In fact we would need a double SSL handshake: one with the HTTP server
and another one with slapd, proxyied by the HTTP server. I am not even
sure it is possible.
Yes, now you see why the steps here
http://www.openldap.org/lists/openldap-technical/200901/msg00037.html
are necessary. You need secure handshakes between all three parties, and
secure credentials that all three parties can trust.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:05 a.m.
New subject: web apps and client certificate authentication
Kurt Zeilenga wrote:
The web application should just authenticate as itself and then use
proxy authorization to act on behalf of the client.
Of course, it has to be authorized to do so.
> But it would be nicer to actually have the client authenticate to slapd
> using its own client certificate.
Why?
I also concur that it would be nice to have a end-to-end authentication
between web client and LDAP server without giving the web application
special rights.
Generally, the web application is part of the service which
encompasses the web server and directory service. They should
already have an appropriate trust relationship.
BTW: This is a very broad assumption not valid in all deployments.
Nevertheless it's always good practice to avoid overly powerful system
components since in this case the web application could have security
problems.
Kerberos with forwardable tickets could be a solution. One could argue
that as a forwardable ticket is a full TGT you also have to trust the
web application a little bit more. But given the limited lifetime of
TGTs the risk is significantly lower than long-time service credentials
for the web application together with the right for doing proxy
authorization.
Ciao, Michael.
12:06 p.m.
New subject: web apps and client certificate authentication
Michael Ströder wrote:
Kurt Zeilenga wrote:
> The web application should just authenticate as itself and then use
> proxy authorization to act on behalf of the client.
> Of course, it has to be authorized to do so.
>
>> But it would be nicer to actually have the client authenticate to slapd
>> using its own client certificate.
> Why?
I also concur that it would be nice to have a end-to-end authentication
between web client and LDAP server without giving the web application
special rights.
But obviously the web application is a man-in-the-middle and current
authentication mechanisms are designed to prevent MITM operation.
> Generally, the web application is part of the service which
> encompasses the web server and directory service. They should
> already have an appropriate trust relationship.
BTW: This is a very broad assumption not valid in all deployments.
Nevertheless it's always good practice to avoid overly powerful system
components since in this case the web application could have security
problems.
Kerberos with forwardable tickets could be a solution. One could argue
that as a forwardable ticket is a full TGT you also have to trust the
web application a little bit more. But given the limited lifetime of
TGTs the risk is significantly lower than long-time service credentials
for the web application together with the right for doing proxy
authorization.
Still, that is your problem - you have to trust the web app to act
appropriately on your behalf. If the web app has security problems, then
sending any form of reusable credentials to it is a mistake.
As a hypothetical solution, one could use a combination of tickets and proxy
authorization. I.e., the web app receives a client credential that contains
both authentication to the web app and to the LDAP server. The web app then
attaches (the relevant portion of) this credential to its proxyAuth'd requests
to the LDAP server. The LDAP server then doesn't have to give blanket proxy
privileges to the app; instead it allows the proxyAuth by virtue of the actual
client credentials also being present.
In an X.509 framework, you might accomplish this by having clients generate
their own sub-certificates (signed by their own client cert) with specific
privilege attributes attached, and very short cert lifetimes (thus being
analogous to Kerberos tickets in usage), and using these sub-certs to
authenticate. Of course, nobody has developed a spec for any of this yet...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:27 a.m.
New subject: web apps and client certificate authentication
Howard Chu wrote:
Michael Ströder wrote:
> Kurt Zeilenga wrote:
>> Generally, the web application is part of the service which
>> encompasses the web server and directory service. They should
>> already have an appropriate trust relationship.
>
> BTW: This is a very broad assumption not valid in all deployments.
> Nevertheless it's always good practice to avoid overly powerful system
> components since in this case the web application could have security
> problems.
>
> Kerberos with forwardable tickets could be a solution. One could argue
> that as a forwardable ticket is a full TGT you also have to trust the
> web application a little bit more. But given the limited lifetime of
> TGTs the risk is significantly lower than long-time service credentials
> for the web application together with the right for doing proxy
> authorization.
Still, that is your problem
Howard, that's not a matter of "your" or "my" problem. In fact I
don't
understand that sentence.
- you have to trust the web app to act
appropriately on your behalf. If the web app has security problems, then
sending any form of reusable credentials to it is a mistake.
In an ideal world there are no security problems at all. The 2nd best
situation is that you know for sure in advance whether a component has
security problems or not. If it has it is a mistake to use it. Period.
But as we all know we're not living in an ideal world. So risk
management generally deals with the probability and the impact of (most
times unknown) risks. You can influence the probability by good software
design, code reviews and such. But that's most times outside the scope
of an administrator setting up a deployment. So the administrator can
only think about mitigating the impact of possible risks. This is not a
black-or-white situation.
And one could argue that the possible impact of security problems in
combination with proxy authz is higher than with a user impersonating
himself on the LDAP connection.
As a hypothetical solution, one could use a combination of tickets
and
proxy authorization. I.e., the web app receives a client credential that
contains both authentication to the web app and to the LDAP server. The
web app then attaches (the relevant portion of) this credential to its
proxyAuth'd requests to the LDAP server. The LDAP server then doesn't
have to give blanket proxy privileges to the app; instead it allows the
proxyAuth by virtue of the actual client credentials also being present.
Well, that's IMHO how forwardable tickets in Kerberos works except that
you don't need proxy authz in that game. (It's on my roadmap to play
with it.)
In an X.509 framework, you might accomplish this by having clients
generate their own sub-certificates (signed by their own client cert)
with specific privilege attributes attached, and very short cert
lifetimes (thus being analogous to Kerberos tickets in usage), and using
these sub-certs to authenticate. Of course, nobody has developed a spec
for any of this yet...
Why so complicated? A challenge-response SASL mech could send the
challenge from the LDAP server to the web app which relays it to the web
browser where the user signs it with his/her private key.
A similar password-based approach would be to map HTTP-DIGEST authc to
SASL DIGEST-MD5. AFAIK that's not possible.
There are some SSO solutions for web apps. E.g. CAS issues a one-time
service ticket (CAS-ST) which is checked by the service against the
central CAS service. This could be sent along in a SASL bind request
with a custom SASL mech and then checked by the LDAP server (see
http://www.ja-sig.org/products/cas/overview/cas2_architecture/index.html).
Or the app could send the CAS-ST in a simple bind request and an overlay
would intercept this and check with the CAS server.
Ciao, Michael.
11:08 a.m.
New subject: web apps and client certificate authentication
Michael Ströder wrote:
Howard Chu wrote:
> Michael Ströder wrote:
>> Kurt Zeilenga wrote:
>>> Generally, the web application is part of the service which
>>> encompasses the web server and directory service. They should
>>> already have an appropriate trust relationship.
>> BTW: This is a very broad assumption not valid in all deployments.
>> Nevertheless it's always good practice to avoid overly powerful system
>> components since in this case the web application could have security
>> problems.
>>
>> Kerberos with forwardable tickets could be a solution. One could argue
>> that as a forwardable ticket is a full TGT you also have to trust the
>> web application a little bit more. But given the limited lifetime of
>> TGTs the risk is significantly lower than long-time service credentials
>> for the web application together with the right for doing proxy
>> authorization.
> Still, that is your problem
Howard, that's not a matter of "your" or "my" problem. In fact I
don't
understand that sentence.
Generic "your" - probably should have said "the" instead.
> - you have to trust the web app to act
> appropriately on your behalf. If the web app has security problems, then
> sending any form of reusable credentials to it is a mistake.
And one could argue that the possible impact of security problems in
combination with proxy authz is higher than with a user impersonating
himself on the LDAP connection.
Yes, depending on how much freedom the proxying identity has. I should point
out that OpenLDAP's ACLs allow you to define separate privileges for a user
being proxied, vs a user that is authenticated directly. As such, you can
easily limit the damage that an untrusted proxy can inflict on a system...
> As a hypothetical solution, one could use a combination of
tickets and
> proxy authorization. I.e., the web app receives a client credential that
> contains both authentication to the web app and to the LDAP server. The
> web app then attaches (the relevant portion of) this credential to its
> proxyAuth'd requests to the LDAP server. The LDAP server then doesn't
> have to give blanket proxy privileges to the app; instead it allows the
> proxyAuth by virtue of the actual client credentials also being present.
Well, that's IMHO how forwardable tickets in Kerberos works except that
you don't need proxy authz in that game. (It's on my roadmap to play
with it.)
But a forwardable TGT is like a blank check - it can be used to acquire any
other service tickets. Again, if you don't trust the app in the middle, this
is not a good solution.
> In an X.509 framework, you might accomplish this by having
clients
> generate their own sub-certificates (signed by their own client cert)
> with specific privilege attributes attached, and very short cert
> lifetimes (thus being analogous to Kerberos tickets in usage), and using
> these sub-certs to authenticate. Of course, nobody has developed a spec
> for any of this yet...
Why so complicated? A challenge-response SASL mech could send the
challenge from the LDAP server to the web app which relays it to the web
browser where the user signs it with his/her private key.
Because a scheme like what you describe is inadequate. One of the factors in
strong authentication is *mutual* authentication of all parties - proving that
the client is who he claims to be and the server is who it claims to be. A
pass-thru scheme like you describe will prove the client and LDAP server's
identity, but will not establish anything about the web app's authenticity.
When you have multiple parties in a conversation, all of them must be
authenticated to the same level of trust, otherwise the whole exercise is futile.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:55 a.m.
New subject: web apps and client certificate authentication
Howard Chu wrote:
Michael Ströder wrote:
> Howard Chu wrote:
>> As a hypothetical solution, one could use a combination of tickets and
>> proxy authorization. I.e., the web app receives a client credential that
>> contains both authentication to the web app and to the LDAP server. The
>> web app then attaches (the relevant portion of) this credential to its
>> proxyAuth'd requests to the LDAP server. The LDAP server then doesn't
>> have to give blanket proxy privileges to the app; instead it allows the
>> proxyAuth by virtue of the actual client credentials also being present.
>
> Well, that's IMHO how forwardable tickets in Kerberos works except that
> you don't need proxy authz in that game. (It's on my roadmap to play
> with it.)
But a forwardable TGT is like a blank check - it can be used to acquire
any other service tickets.
Yes. But in opposite to a clear-text password typed in a web form the
TGT has a limited lifetime like the short-time cert you proposed.
Again, if you don't trust the app in the middle, this is not a
good
solution.
Yes, but the trust is not a black-or-white decision. If I surely know
that the web app is flawed it's a big mistake to use it anyway.
>> In an X.509 framework, you might accomplish this by having
clients
>> generate their own sub-certificates (signed by their own client cert)
>> with specific privilege attributes attached, and very short cert
>> lifetimes (thus being analogous to Kerberos tickets in usage), and using
>> these sub-certs to authenticate. Of course, nobody has developed a spec
>> for any of this yet...
>
> Why so complicated? A challenge-response SASL mech could send the
> challenge from the LDAP server to the web app which relays it to the web
> browser where the user signs it with his/her private key.
Because a scheme like what you describe is inadequate. One of the
factors in strong authentication is *mutual* authentication of all
parties - proving that the client is who he claims to be and the server
is who it claims to be. A pass-thru scheme like you describe will prove
the client and LDAP server's identity, but will not establish anything
about the web app's authenticity. When you have multiple parties in a
conversation, all of them must be authenticated to the same level of
trust, otherwise the whole exercise is futile.
"Web app's authenticity" is a very broad term. Even when authenticating
the web server where the app is running by validating the SSL server
cert you cannot verify the "web app's authenticity". So to some degree
you have to trust the web app itself (like Kurt already mentioned). But
again: Trust is not a black-or-white decision.
I see no reason why I shouldn't connect via HTTPS to the web app and
then have a pass-through authentication mechanism between the web
browser and the LDAP server to impersonate the user himself on the LDAP
connection. This is pretty similar to the user typing in his password
into a login form of the web app except that no clear-text longtime
credential has to be passed to the web app. (With assuming the web app
does not enforce any authorization at all and therefore does not have to
authenticate the user.)
Ciao, Michael.
5421
days inactive
5435
days old
openldap-technical@openldap.org
12 comments
4 participants
participants (4)
-
Howard Chu -
Kurt Zeilenga -
manu＠netbsd.org -
Michael Ströder