MySQL as credential store in Heimdal

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

MySQL as credential store in Heimdal

Ali Gholami
Hi,

I wonder if there is any relational database compatibility with Heimdal
to store principals and credentials. I know there is LDAP support for
Heimdal but that causes overhead for enterprises to adapt MySQL to
support LDAP. For instance user management in LDAP through command-line
or synchronizing MySQL and LDAP server together causes usability in many
enterprise applications.

I think it might be very useful to have such compatibility for Kerberos
to store user credentials in MySQL backend. This makes many existing
applications to use Kerberos services easily without the need of
deploying LDAP services.

I could not find any useful document ion for this problem. Is it
intentionally Heimdal does not support MySQL(or any relational database)
as backend or it's just a missing feature?

Best regards
Ali Gholami

Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Howard Chu
Ali Gholami wrote:

> Hi,
>
> I wonder if there is any relational database compatibility with Heimdal
> to store principals and credentials. I know there is LDAP support for
> Heimdal but that causes overhead for enterprises to adapt MySQL to
> support LDAP. For instance user management in LDAP through command-line
> or synchronizing MySQL and LDAP server together causes usability in many
> enterprise applications.
>
> I think it might be very useful to have such compatibility for Kerberos
> to store user credentials in MySQL backend. This makes many existing
> applications to use Kerberos services easily without the need of
> deploying LDAP services.
>
> I could not find any useful document ion for this problem. Is it
> intentionally Heimdal does not support MySQL(or any relational database)
> as backend or it's just a missing feature?

Relational databases would be a couple orders of magnitude slower than LDAP for this type of workload. Storing user profiles/credentials in SQL is a very poor use of databases.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Ali Gholami
Hi Howard,

Thanks for the reply. I agree with you in some extent that a relation
database in general might performs slower than e.g OpenLDAP for reads.
But as far as I know, some popular databases such as MySQL can be tuned
for high availability scenarios to support large number of
operations/second. Even if the MySQL would be run through
network-database(NDB) technology that would even be much more faster
(4.3 BN reads per minute). This has been discussed in this post:
http://mikaelronstrom.blogspot.se/2012/05/mysql-cluster-72-achieves-43bn-reads.html.
I believe in some cases OpenLDAP utilizes MySQL NDB as well to achieve
high performance operations.

I can not say an exact number to indicate magnitude of a database for a
small or medium sized application within an enterprise. But I'm pretty
sure number of users would not exceed over a million or such (here I'm
not talking about Facebook or Google etc that have hundred millions of
users with their own authentication systems).

Also when it comes to development efforts, many modern Web frameworks
have significant amount of support for relational databases. A good
example is Java Enterprise Edition which is a popular Web development
framework, where easily maps the database relations to entities within
an applications. I think using LDAP in this example would require a
remarkable amount of software development for an application which does
not require millions of authentication requests/second. In this scenario
I can claim there is a poor choice to utilize LDAP as directory protocol
to store credentials.

All in all, I'm not against OpenLDAP as a credential/directory server
since I have used it in several projects and indeed for some scenarios
LDAP is an excellent choice. But my point is for those classes of
applications with the immediate need of a relational database as
bankend, it might be very useful to have such support in Kerberos.

Best regards
Ali

On 2015-02-12 21:47, Howard Chu wrote:

> Ali Gholami wrote:
>> Hi,
>>
>> I wonder if there is any relational database compatibility with Heimdal
>> to store principals and credentials. I know there is LDAP support for
>> Heimdal but that causes overhead for enterprises to adapt MySQL to
>> support LDAP. For instance user management in LDAP through command-line
>> or synchronizing MySQL and LDAP server together causes usability in many
>> enterprise applications.
>>
>> I think it might be very useful to have such compatibility for Kerberos
>> to store user credentials in MySQL backend. This makes many existing
>> applications to use Kerberos services easily without the need of
>> deploying LDAP services.
>>
>> I could not find any useful document ion for this problem. Is it
>> intentionally Heimdal does not support MySQL(or any relational database)
>> as backend or it's just a missing feature?
>
> Relational databases would be a couple orders of magnitude slower than
> LDAP for this type of workload. Storing user profiles/credentials in
> SQL is a very poor use of databases.
>

Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Jeffrey Hutzelman
On Thu, 2015-02-12 at 23:02 +0100, Ali Gholami wrote:

> All in all, I'm not against OpenLDAP as a credential/directory server
> since I have used it in several projects and indeed for some scenarios
> LDAP is an excellent choice. But my point is for those classes of
> applications with the immediate need of a relational database as
> bankend, it might be very useful to have such support in Kerberos.


I think you're confused.  Kerberos is a trusted-third-party
authentication system, not a password database.  Its backend database is
private to the KDC, and contains authentication secrets which, as a
fundamental property of the system, _must_ be known only to the KDC.
Application support for the backend is a non-issue because, if you ever
gave an application access to the KDC's database, it would completely
compromise the security of the entire realm.

Some people have found it useful to use an LDAP server as the backend
for various reasons, but this requires a _private_ LDAP server not
accessible to applications and/or very careful configuration to avoid
exposing secrets.  It can be useful to store Kerberos data and
general-purpose directory data in the same database, especially for
account management purposes.  However, that does not mean that
applications can somehow bypass Kerberos and verify passwords by
querying the LDAP server.

-- Jeff

Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Ali Gholami
Hi Jeff,

Thanks for the comments. Your description perfectly makes sense not to
confuse the Kerberos role as a third-party
authentication system. I should have elaborated more on using MySQL in
Kerberos since I didn't mean to
allow an application bypassing Kerberos for authentication.

Currently, Kerberos (Heimdal) supports the following options for
credentials store:

1. Kerberos  <--------------->  Native buit-in credential database
2. Kerberos  <--------------->  OpenLDAP
3. Kerberos  <--------------->  OpenLDAP <---------------> MySQL (or any
supported relational database to achieve high performance)

I was thinking for some scenarios to use MySQL as backend directly
instead of interfacing it with LDAP (Kerberos <---------------> MySQL).
This does not necessarily mean applications share database with the
Kerbeors credential store. Applications and Kerberos can run two
instances of MySQL that are agnostic to each other. But as you know,
maintaining a Kerberos native database or OpenLDAP database in a modern
web application through a GUI is not very practical and it just makes it
more complicated. While many web frameworks support relational databases
easily for user administration through GUI.

Best regards,
Ali


On 2015-02-13 00:36, Jeffrey Hutzelman wrote:

> On Thu, 2015-02-12 at 23:02 +0100, Ali Gholami wrote:
>
>> All in all, I'm not against OpenLDAP as a credential/directory server
>> since I have used it in several projects and indeed for some scenarios
>> LDAP is an excellent choice. But my point is for those classes of
>> applications with the immediate need of a relational database as
>> bankend, it might be very useful to have such support in Kerberos.
>
> I think you're confused.  Kerberos is a trusted-third-party
> authentication system, not a password database.  Its backend database is
> private to the KDC, and contains authentication secrets which, as a
> fundamental property of the system, _must_ be known only to the KDC.
> Application support for the backend is a non-issue because, if you ever
> gave an application access to the KDC's database, it would completely
> compromise the security of the entire realm.
>
> Some people have found it useful to use an LDAP server as the backend
> for various reasons, but this requires a _private_ LDAP server not
> accessible to applications and/or very careful configuration to avoid
> exposing secrets.  It can be useful to store Kerberos data and
> general-purpose directory data in the same database, especially for
> account management purposes.  However, that does not mean that
> applications can somehow bypass Kerberos and verify passwords by
> querying the LDAP server.
>
> -- Jeff
>

Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Howard Chu
Ali Gholami wrote:

> Hi Jeff,
>
> Thanks for the comments. Your description perfectly makes sense not to
> confuse the Kerberos role as a third-party
> authentication system. I should have elaborated more on using MySQL in
> Kerberos since I didn't mean to
> allow an application bypassing Kerberos for authentication.
>
> Currently, Kerberos (Heimdal) supports the following options for
> credentials store:
>
> 1. Kerberos  <--------------->  Native buit-in credential database
> 2. Kerberos  <--------------->  OpenLDAP
> 3. Kerberos  <--------------->  OpenLDAP <---------------> MySQL (or any
> supported relational database to achieve high performance)

"High performance" is a joke, right? There is no relational database in the world within an order of magnitude of OpenLDAP's performance.

You mentioned OpenLDAP supporting MySQL NDB Cluster - that was an OpenLDAP backend that talks directly to the NDB data API, there is no SQL layer involved there. Study slide 27 of the NDB presentation very carefully.

http://symas.com/docs/LDAPConNDB2009.pdf

Using the actual *SQL* interface won't get you more than 100s of authentications/second, as opposed to *tens of thousands*/sec on that hardware. Fast forward to today with our LMDB database (which is also natively supported in Heimdal) and the difference is yet another order of magnitude greater.

http://symas.com/docs/2014FOSDEM-WhatsNewInOpenLDAP.pdf (slide #15)

> I was thinking for some scenarios to use MySQL as backend directly
> instead of interfacing it with LDAP (Kerberos <---------------> MySQL).
> This does not necessarily mean applications share database with the
> Kerbeors credential store. Applications and Kerberos can run two
> instances of MySQL that are agnostic to each other. But as you know,
> maintaining a Kerberos native database or OpenLDAP database in a modern
> web application through a GUI is not very practical and it just makes it
> more complicated. While many web frameworks support relational databases
> easily for user administration through GUI.

There's projects like web2ldap, webmin, etc... Use the right tool for the job. SQL in any form is the wrong tool for this job.

> Best regards,
> Ali
>
>
> On 2015-02-13 00:36, Jeffrey Hutzelman wrote:
>> On Thu, 2015-02-12 at 23:02 +0100, Ali Gholami wrote:
>>
>>> All in all, I'm not against OpenLDAP as a credential/directory server
>>> since I have used it in several projects and indeed for some scenarios
>>> LDAP is an excellent choice. But my point is for those classes of
>>> applications with the immediate need of a relational database as
>>> bankend, it might be very useful to have such support in Kerberos.
>>
>> I think you're confused.  Kerberos is a trusted-third-party
>> authentication system, not a password database.  Its backend database is
>> private to the KDC, and contains authentication secrets which, as a
>> fundamental property of the system, _must_ be known only to the KDC.
>> Application support for the backend is a non-issue because, if you ever
>> gave an application access to the KDC's database, it would completely
>> compromise the security of the entire realm.
>>
>> Some people have found it useful to use an LDAP server as the backend
>> for various reasons, but this requires a _private_ LDAP server not
>> accessible to applications and/or very careful configuration to avoid
>> exposing secrets.  It can be useful to store Kerberos data and
>> general-purpose directory data in the same database, especially for
>> account management purposes.  However, that does not mean that
>> applications can somehow bypass Kerberos and verify passwords by
>> querying the LDAP server.
>>
>> -- Jeff
>>
>


--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Howard Chu
Howard Chu wrote:

> Ali Gholami wrote:
>> I was thinking for some scenarios to use MySQL as backend directly
>> instead of interfacing it with LDAP (Kerberos <---------------> MySQL).
>> This does not necessarily mean applications share database with the
>> Kerbeors credential store. Applications and Kerberos can run two
>> instances of MySQL that are agnostic to each other. But as you know,
>> maintaining a Kerberos native database or OpenLDAP database in a modern
>> web application through a GUI is not very practical and it just makes it
>> more complicated. While many web frameworks support relational databases
>> easily for user administration through GUI.
>
> There's projects like web2ldap, webmin, etc... Use the right tool for
> the job. SQL in any form is the wrong tool for this job.

Leaving the performance question aside, there's also the obvious question of security. Web interfaces to SQL databases are notorious for being vulnerable to SQL injection attacks. (Meet my good friend Little Bobby Tables...) All text-based command languages are vulnerable. LDAP is *not* vulnerable, since it's a binary protocol with tightly defined message structure - there is nowhere to inject anything.

Use of SQL for anything security-sensitive and web-facing is extremely unwise.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

paul kölle
In reply to this post by Ali Gholami
Am 13.02.2015 um 08:26 schrieb Ali Gholami:
[snip]

>
> 1. Kerberos  <--------------->  Native buit-in credential database
> 2. Kerberos  <--------------->  OpenLDAP
> 3. Kerberos  <--------------->  OpenLDAP <---------------> MySQL (or any
> supported relational database to achieve high performance)
>
> I was thinking for some scenarios to use MySQL as backend directly
> instead of interfacing it with LDAP (Kerberos <---------------> MySQL).
> This does not necessarily mean applications share database with the
> Kerbeors credential store. Applications and Kerberos can run two
> instances of MySQL that are agnostic to each other. But as you know,
> maintaining a Kerberos native database or OpenLDAP database in a modern
> web application through a GUI is not very practical and it just makes it
> more complicated. While many web frameworks support relational databases
> easily for user administration through GUI.

"modern" web applications are a security nightmare. Usually there is one
set of credentials with full access to the DB and all auth/autz stuff
needs to be handled at the application layer (ignoring MSSQL for the
moment ;))

You want to expose kerberos keys to web applications for convenience and
confronted with the security implications you come up with "Applications
and Kerberos can run two instances of MySQL that are agnostic to each
other." - leaving what? How are "web applications" supposed to change
passwords if you have two seperated databases?

I hope this does not sound too harsh. But I think in this case you just
can't have your cake and eat it too.

cheers
  Paul

PS: There are already tools to allow admins to expose krb5 long term
secrets on the wire (think pam_krb5). No need to add another one ;)

Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Ali Gholami
Hi Paul,

Thanks for the comments. I agree that web applications have many
security weaknesses but having a trade-off provides a good balance
between security and usability.

In my previous emails I mentioned Java EE (enterprise edition) as a
popular web framework which solves many of the weaknesses in web
applications such as SQL injection, cookie theft, secure channels etc.
This is a fact that not all applications require the same level of
security (cloud applications may use same credential store as
applications and have solutions how to protect the credentials in event
of disclosure). So in cloud environments where agility and cost
reduction are main concerns, deploying Kerberos with MySQL might make sense.

I believe in Java EE application security model, application does not
have direct access to credential database but through RPC calls embedded
in enterprise java beans (EJB). This means even if Kerberos uses MySQL
as credential store still there is a good level of security (instead of
changing passwords by SSH, HTTPS can be used). Also keeping credentials
in the same database as application is not an issue in JavaEE framework,
since it's not a dumb web application so that credentials can be
disclosed through a SQL injection. Java security manager enforces
authorized access to different components through the application
server. But I understand any vulnerability in the application server
(e.g. Apache Tomcat) remains a security threat to the credential store.
I think Kerberos is already integrated in some application server with
Java EE
(https://danieljamesscott.org/10-articles/configuration-guides/15-glassfish-kerberosldap-integration.html).


I would say many relational databases store sensitive information which
are not less important than user credentials databases. If relational
databases are that terrible in the web context, then I would rethink to
use any of them to store sensitive data!


Best regards
Ali


> Am 13.02.2015 um 08:26 schrieb Ali Gholami:
> [snip]
>
>>
>> 1. Kerberos  <--------------->  Native buit-in credential database
>> 2. Kerberos  <--------------->  OpenLDAP
>> 3. Kerberos  <--------------->  OpenLDAP <---------------> MySQL (or any
>> supported relational database to achieve high performance)
>>
>> I was thinking for some scenarios to use MySQL as backend directly
>> instead of interfacing it with LDAP (Kerberos <---------------> MySQL).
>> This does not necessarily mean applications share database with the
>> Kerbeors credential store. Applications and Kerberos can run two
>> instances of MySQL that are agnostic to each other. But as you know,
>> maintaining a Kerberos native database or OpenLDAP database in a modern
>> web application through a GUI is not very practical and it just makes it
>> more complicated. While many web frameworks support relational databases
>> easily for user administration through GUI.
>
> "modern" web applications are a security nightmare. Usually there is
> one set of credentials with full access to the DB and all auth/autz
> stuff needs to be handled at the application layer (ignoring MSSQL for
> the moment ;))
>
> You want to expose kerberos keys to web applications for convenience
> and confronted with the security implications you come up with
> "Applications and Kerberos can run two instances of MySQL that are
> agnostic to each other." - leaving what? How are "web applications"
> supposed to change passwords if you have two seperated databases?
>
> I hope this does not sound too harsh. But I think in this case you
> just can't have your cake and eat it too.
>
> cheers
>  Paul
>
> PS: There are already tools to allow admins to expose krb5 long term
> secrets on the wire (think pam_krb5). No need to add another one ;)
>
Reply | Threaded
Open this post in threaded view
|

RE: MySQL as credential store in Heimdal

Huang, Peter
This has been interesting discussion so I'll add my 2 cents here.   There are two contexts that are discuss here in my mind:
1) the security protection on credential and authn performance.   At Howard pointed out, storing credential secret will not get the security protection and performance you want to achieve based on past implementations (at least the one I have to deal with).   Therefore, I won't want to put the password secret in a relational database unless I have no choice.
2) the session token and the SSO aspect.   In order to achieve SSO in a cloud like environment, storing session token in a relational database will allow one have geo transparent access (e.g. EJB session can be replicated).  Is this worthwhile the investment, it will be up your use case.

regards
-peter
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ali Gholami
Sent: Friday, February 13, 2015 6:38 AM
To: [hidden email]; Paul
Cc: Howard Chu
Subject: Re: MySQL as credential store in Heimdal

Hi Paul,

Thanks for the comments. I agree that web applications have many security weaknesses but having a trade-off provides a good balance between security and usability.

In my previous emails I mentioned Java EE (enterprise edition) as a popular web framework which solves many of the weaknesses in web applications such as SQL injection, cookie theft, secure channels etc.
This is a fact that not all applications require the same level of security (cloud applications may use same credential store as applications and have solutions how to protect the credentials in event of disclosure). So in cloud environments where agility and cost reduction are main concerns, deploying Kerberos with MySQL might make sense.

I believe in Java EE application security model, application does not have direct access to credential database but through RPC calls embedded in enterprise java beans (EJB). This means even if Kerberos uses MySQL as credential store still there is a good level of security (instead of changing passwords by SSH, HTTPS can be used). Also keeping credentials in the same database as application is not an issue in JavaEE framework, since it's not a dumb web application so that credentials can be disclosed through a SQL injection. Java security manager enforces authorized access to different components through the application server. But I understand any vulnerability in the application server (e.g. Apache Tomcat) remains a security threat to the credential store.
I think Kerberos is already integrated in some application server with Java EE (https://danieljamesscott.org/10-articles/configuration-guides/15-glassfish-kerberosldap-integration.html).


I would say many relational databases store sensitive information which are not less important than user credentials databases. If relational databases are that terrible in the web context, then I would rethink to use any of them to store sensitive data!


Best regards
Ali


> Am 13.02.2015 um 08:26 schrieb Ali Gholami:
> [snip]
>
>>
>> 1. Kerberos  <--------------->  Native buit-in credential database 2.
>> Kerberos  <--------------->  OpenLDAP 3. Kerberos  <--------------->  
>> OpenLDAP <---------------> MySQL (or any supported relational
>> database to achieve high performance)
>>
>> I was thinking for some scenarios to use MySQL as backend directly
>> instead of interfacing it with LDAP (Kerberos <---------------> MySQL).
>> This does not necessarily mean applications share database with the
>> Kerbeors credential store. Applications and Kerberos can run two
>> instances of MySQL that are agnostic to each other. But as you know,
>> maintaining a Kerberos native database or OpenLDAP database in a
>> modern web application through a GUI is not very practical and it
>> just makes it more complicated. While many web frameworks support
>> relational databases easily for user administration through GUI.
>
> "modern" web applications are a security nightmare. Usually there is
> one set of credentials with full access to the DB and all auth/autz
> stuff needs to be handled at the application layer (ignoring MSSQL for
> the moment ;))
>
> You want to expose kerberos keys to web applications for convenience
> and confronted with the security implications you come up with
> "Applications and Kerberos can run two instances of MySQL that are
> agnostic to each other." - leaving what? How are "web applications"
> supposed to change passwords if you have two seperated databases?
>
> I hope this does not sound too harsh. But I think in this case you
> just can't have your cake and eat it too.
>
> cheers
>  Paul
>
> PS: There are already tools to allow admins to expose krb5 long term
> secrets on the wire (think pam_krb5). No need to add another one ;)
>
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Ali Gholami
Hi Peter,

Right, I agree with Howard that storing credentials in a dedicated LDAP
server provides better security. Though, I would not like to discuss the
performance achievements since there are not measures to compare similar
environments. For instance, if I have a Java EE application instance
running and measure the performance with/without LDAP/MySQL in Kerbeors,
it provides an accurate arguments on performance.

In the attached diagram, users get authenticated through HTTPS in first
step. The request is passed through the web application to the Kerberos
custom realm where an RPC callback authenticate the user with KDC. KDC
verifies the credentials and send the authentication results to the
custom realm. Then after authentication user will be able to change
passwords through the EJB container where authorization is enforced
(step2).

Regarding EJB replication, If I understand it correctly it's done
through cookie-based sessions. I've made a simple diagram as attached
where a custom authentication realm [1] for Kerberos is used. The
proposed authentication method is not a cookie-based design where EJBs
could be replicated. JavaEE provides secure sessions where I think it's
not that easy to replicate a stolen session. Or if I'm wrong I would
appreciate any good reference so I investigate this.

Thanks, Ali

[1] http://docs.oracle.com/cd/E19226-01/820-7695/6niugeskh/index.html



On 2015-02-13 16:04, Huang, Peter wrote:

> This has been interesting discussion so I'll add my 2 cents here.   There are two contexts that are discuss here in my mind:
> 1) the security protection on credential and authn performance.   At Howard pointed out, storing credential secret will not get the security protection and performance you want to achieve based on past implementations (at least the one I have to deal with).   Therefore, I won't want to put the password secret in a relational database unless I have no choice.
> 2) the session token and the SSO aspect.   In order to achieve SSO in a cloud like environment, storing session token in a relational database will allow one have geo transparent access (e.g. EJB session can be replicated).  Is this worthwhile the investment, it will be up your use case.
>
> regards
> -peter
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Ali Gholami
> Sent: Friday, February 13, 2015 6:38 AM
> To: [hidden email]; Paul
> Cc: Howard Chu
> Subject: Re: MySQL as credential store in Heimdal
>
> Hi Paul,
>
> Thanks for the comments. I agree that web applications have many security weaknesses but having a trade-off provides a good balance between security and usability.
>
> In my previous emails I mentioned Java EE (enterprise edition) as a popular web framework which solves many of the weaknesses in web applications such as SQL injection, cookie theft, secure channels etc.
> This is a fact that not all applications require the same level of security (cloud applications may use same credential store as applications and have solutions how to protect the credentials in event of disclosure). So in cloud environments where agility and cost reduction are main concerns, deploying Kerberos with MySQL might make sense.
>
> I believe in Java EE application security model, application does not have direct access to credential database but through RPC calls embedded in enterprise java beans (EJB). This means even if Kerberos uses MySQL as credential store still there is a good level of security (instead of changing passwords by SSH, HTTPS can be used). Also keeping credentials in the same database as application is not an issue in JavaEE framework, since it's not a dumb web application so that credentials can be disclosed through a SQL injection. Java security manager enforces authorized access to different components through the application server. But I understand any vulnerability in the application server (e.g. Apache Tomcat) remains a security threat to the credential store.
> I think Kerberos is already integrated in some application server with Java EE (https://danieljamesscott.org/10-articles/configuration-guides/15-glassfish-kerberosldap-integration.html).
>
>
> I would say many relational databases store sensitive information which are not less important than user credentials databases. If relational databases are that terrible in the web context, then I would rethink to use any of them to store sensitive data!
>
>
> Best regards
> Ali
>
>
>> Am 13.02.2015 um 08:26 schrieb Ali Gholami:
>> [snip]
>>
>>> 1. Kerberos  <--------------->  Native buit-in credential database 2.
>>> Kerberos  <--------------->  OpenLDAP 3. Kerberos  <--------------->
>>> OpenLDAP <---------------> MySQL (or any supported relational
>>> database to achieve high performance)
>>>
>>> I was thinking for some scenarios to use MySQL as backend directly
>>> instead of interfacing it with LDAP (Kerberos <---------------> MySQL).
>>> This does not necessarily mean applications share database with the
>>> Kerbeors credential store. Applications and Kerberos can run two
>>> instances of MySQL that are agnostic to each other. But as you know,
>>> maintaining a Kerberos native database or OpenLDAP database in a
>>> modern web application through a GUI is not very practical and it
>>> just makes it more complicated. While many web frameworks support
>>> relational databases easily for user administration through GUI.
>> "modern" web applications are a security nightmare. Usually there is
>> one set of credentials with full access to the DB and all auth/autz
>> stuff needs to be handled at the application layer (ignoring MSSQL for
>> the moment ;))
>>
>> You want to expose kerberos keys to web applications for convenience
>> and confronted with the security implications you come up with
>> "Applications and Kerberos can run two instances of MySQL that are
>> agnostic to each other." - leaving what? How are "web applications"
>> supposed to change passwords if you have two seperated databases?
>>
>> I hope this does not sound too harsh. But I think in this case you
>> just can't have your cake and eat it too.
>>
>> cheers
>>   Paul
>>
>> PS: There are already tools to allow admins to expose krb5 long term
>> secrets on the wire (think pam_krb5). No need to add another one ;)
>>


customrealm.png (63K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Henry B Hotz
In reply to this post by Howard Chu

On Feb 13, 2015, at 2:00 AM, Howard Chu <[hidden email]> wrote:

> Ali Gholami wrote:
>
>> Currently, Kerberos (Heimdal) supports the following options for
>> credentials store:
>>
>> 1. Kerberos  <--------------->  Native buit-in credential database
>> 2. Kerberos  <--------------->  OpenLDAP
>> 3. Kerberos  <--------------->  OpenLDAP <---------------> MySQL (or any
>> supported relational database to achieve high performance)
>
> "High performance" is a joke, right? There is no relational database in the world within an order of magnitude of OpenLDAP's performance.
>
> You mentioned OpenLDAP supporting MySQL NDB Cluster - that was an OpenLDAP backend that talks directly to the NDB data API, there is no SQL layer involved there. Study slide 27 of the NDB presentation very carefully.
>
> http://symas.com/docs/LDAPConNDB2009.pdf
>
> Using the actual *SQL* interface won't get you more than 100s of authentications/second, as opposed to *tens of thousands*/sec on that hardware. Fast forward to today with our LMDB database (which is also natively supported in Heimdal) and the difference is yet another order of magnitude greater.
>
> http://symas.com/docs/2014FOSDEM-WhatsNewInOpenLDAP.pdf (slide #15)

I doubt there are many places where Kerberos provides more than 100’s of authN/sec. Those that do likely have multiple KDCs for other reasons anyway and can load-share. I doubt the performance issues are important per se for very many places as long as ordinary passwords are used.

OTOH if you’re doing PKINIT with some PKI system, possibly including smart cards, then the cost of the initial authentication is substantially higher and looking at performance *should* be done.

Just my $0.02.

Personal email.  [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Nico Williams
On Mon, Feb 16, 2015 at 10:49 AM, Henry B (Hank) Hotz, CISSP
<[hidden email]> wrote:
> On Feb 13, 2015, at 2:00 AM, Howard Chu <[hidden email]> wrote:
> I doubt there are many places where Kerberos provides more than 100’s of authN/sec. Those that do likely have multiple KDCs for other reasons anyway and can load-share. I doubt the performance issues are important per se for very many places as long as ordinary passwords are used.

You might be surprised...  Some Java implementations acquire a TGT on
every acceptor credential acquisition (to validate the keytab, natch).
The fix for that is to use the JNI shim, of course.  Still, the point
is that in some environments load is high and amplified.  Still,
modest modern hardware the load is quite manageable.

> OTOH if you’re doing PKINIT with some PKI system, possibly including smart cards, then the cost of the initial authentication is substantially higher and looking at performance *should* be done.

Yeah, but if you're using smartcards the limiting factor is on the
client side.  There's also anon PKINIT for FAST.  But all this
newfangled stuff is still in the noise in most Kerberos environments.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Paul Robert Marino
same for the Apache Kerberos authorization module and you don't have
credential caching enabled in the Apache module. its astounding!
In addition I've seen similar behavior from the LDAP Apache module
when used in conjunction with saslauthd.



On Tue, Feb 17, 2015 at 1:03 PM, Nico Williams <[hidden email]> wrote:

> On Mon, Feb 16, 2015 at 10:49 AM, Henry B (Hank) Hotz, CISSP
> <[hidden email]> wrote:
>> On Feb 13, 2015, at 2:00 AM, Howard Chu <[hidden email]> wrote:
>> I doubt there are many places where Kerberos provides more than 100’s of authN/sec. Those that do likely have multiple KDCs for other reasons anyway and can load-share. I doubt the performance issues are important per se for very many places as long as ordinary passwords are used.
>
> You might be surprised...  Some Java implementations acquire a TGT on
> every acceptor credential acquisition (to validate the keytab, natch).
> The fix for that is to use the JNI shim, of course.  Still, the point
> is that in some environments load is high and amplified.  Still,
> modest modern hardware the load is quite manageable.
>
>> OTOH if you’re doing PKINIT with some PKI system, possibly including smart cards, then the cost of the initial authentication is substantially higher and looking at performance *should* be done.
>
> Yeah, but if you're using smartcards the limiting factor is on the
> client side.  There's also anon PKINIT for FAST.  But all this
> newfangled stuff is still in the noise in most Kerberos environments.
>
> Nico
> --
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Nico Williams
On Tue, Feb 17, 2015 at 05:04:12PM -0500, Paul Robert Marino wrote:
> same for the Apache Kerberos authorization module and you don't have
> credential caching enabled in the Apache module. its astounding!
> In addition I've seen similar behavior from the LDAP Apache module
> when used in conjunction with saslauthd.

Horrible.

Where's the time machine?

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Nico Williams
In reply to this post by Ali Gholami
On Thu, Feb 12, 2015 at 06:54:18PM +0100, Ali Gholami wrote:
> I wonder if there is any relational database compatibility with
> Heimdal to store principals and credentials. I know there is LDAP
> support for Heimdal but that causes overhead for enterprises to
> adapt MySQL to support LDAP. For instance user management in LDAP
> through command-line or synchronizing MySQL and LDAP server together
> causes usability in many enterprise applications.

If you mean the KDC-side database, yes, there's no reason that you
couldn't store it in any DB you like.

There have been two types thus far in actual implementations:

 - key/value store, with the key being the principal name and the value
   being an encoding of a complex data structure that includes keying
   material;

 - some DB technology, generally LDAP.

LDAP is supported by Heimdal and MIT Kerberos, and something close to it
is used by Microsoft's Active Directory.

How much the LDAP server backend normalizes the data or not is an
implementation detail.  LDAP does not fully specify backend database
semantics (e.g., referential integrity), but implementors generally
provide some such semantics.

There is no reason at all that you couldn't use a relational backend.

The main issue is how to interface with the KDC.  For existing KDCs your
only choices would be: synchronize to the key/value KDB, or expose an
LDAP interface.  For Heimdal and MIT a third choice would be to
implement a backend that talks to your DB however you like.

> I think it might be very useful to have such compatibility for
> Kerberos to store user credentials in MySQL backend. This makes many
> existing applications to use Kerberos services easily without the
> need of deploying LDAP services.

Normalizing the KDB has some administrative benefits.  It slows down
reads unless you have triggers (or application-level equivalents) to
keep denormalized views in sync.

> I could not find any useful document ion for this problem. Is it
> intentionally Heimdal does not support MySQL(or any relational
> database) as backend or it's just a missing feature?

Heimdal's interface to the HDB is very much key/value-like, but the LDAP
backend scatter/gathers the value to/from the LDAP object attributes.
The same approach should work for any other DB.

I've toyed before with extending the Heimdal ASN.1 compiler to support
extensions (semantic extensions, not syntactic ones!) for expressing
mappings to relational (or LDAP) interfaces, so that more of the LDAP
backend and/or a future SQL backend could be generated by the compiler.
But I've never had time to follow through.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Paul Robert Marino
In reply to this post by Nico Williams
Lol
 Yea really most of these Apache modules were written back in the days when every one said they used LDAPv3 but we're doing legacy LDAPv2 simple binds as a single user and reading password fields ‎from an LDAP search to authenticate the user. The same is probably true for Java as well so many of them didn't get much use till recently, as a result many of them have scaling issues they haven't resolved yet.
‎I personally would like to see them issue a cookie after the first successful SASL and or GSSAPI  bind then use that for the remainder of the session but none of them implement this at this time.

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Nico Williams
Sent: Tuesday, February 17, 2015 17:34
To: Paul Robert Marino
Cc: [hidden email] discuss
Subject: Re: MySQL as credential store in Heimdal

On Tue, Feb 17, 2015 at 05:04:12PM -0500, Paul Robert Marino wrote:
> same for the Apache Kerberos authorization module and you don't have
> credential caching enabled in the Apache module. its astounding!
> In addition I've seen similar behavior from the LDAP Apache module
> when used in conjunction with saslauthd.

Horrible.

Where's the time machine?

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Paul Robert Marino
In reply to this post by Nico Williams
Also MongoDb would be a decent choice for a key value pair ‎db like this. In fact it's already based on a similar concept to how Openldap uses sleepy cat

NoSQL is nothing new just a new buzz word for what people did before SQL relational databases. And the old implementations never went away they weren't ever considered by web developers before.

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Nico Williams
Sent: Tuesday, February 17, 2015 17:44
To: [hidden email]; Ali Gholami
Reply To: [hidden email]
Subject: Re: MySQL as credential store in Heimdal

On Thu, Feb 12, 2015 at 06:54:18PM +0100, Ali Gholami wrote:
> I wonder if there is any relational database compatibility with
> Heimdal to store principals and credentials. I know there is LDAP
> support for Heimdal but that causes overhead for enterprises to
> adapt MySQL to support LDAP. For instance user management in LDAP
> through command-line or synchronizing MySQL and LDAP server together
> causes usability in many enterprise applications.

If you mean the KDC-side database, yes, there's no reason that you
couldn't store it in any DB you like.

There have been two types thus far in actual implementations:

- key/value store, with the key being the principal name and the value‎
being an encoding of a complex data structure that includes keying
material;

- some DB technology, generally LDAP.

LDAP is supported by Heimdal and MIT Kerberos, and something close to it
is used by Microsoft's Active Directory.

How much the LDAP server backend normalizes the data or not is an
implementation detail. LDAP does not fully specify backend database
semantics (e.g., referential integrity), but implementors generally
provide some such semantics.

There is no reason at all that you couldn't use a relational backend.

The main issue is how to interface with the KDC. For existing KDCs your
only choices would be: synchronize to the key/value KDB, or expose an
LDAP interface. For Heimdal and MIT a third choice would be to
implement a backend that talks to your DB however you like.

> I think it might be very useful to have such compatibility for
> Kerberos to store user credentials in MySQL backend. This makes many
> existing applications to use Kerberos services easily without the
> need of deploying LDAP services.

Normalizing the KDB has some administrative benefits. It slows down
reads unless you have triggers (or application-level equivalents) to
keep denormalized views in sync.

> I could not find any useful document ion for this problem. Is it
> intentionally Heimdal does not support MySQL(or any relational
> database) as backend or it's just a missing feature?

Heimdal's interface to the HDB is very much key/value-like, but the LDAP
backend scatter/gathers the value to/from the LDAP object attributes.
The same approach should work for any other DB.

I've toyed before with extending the Heimdal ASN.1 compiler to support
extensions (semantic extensions, not syntactic ones!) for expressing
mappings to relational (or LDAP) interfaces, so that more of the LDAP
backend and/or a future SQL backend could be generated by the compiler.
But I've never had time to follow through.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Ali Gholami
In reply to this post by Nico Williams
Hi Nico,

Thank you very much for the explanation. I pretty much got my answer as
I just wanted to make sure if there is support for MySQL as credential
store in KDC.

Using relational databases as backend of KDC in some ways provides more
convenient integration of Kerbeors with applications. Since many people
are familiar with SQL and also relational databases have been around for
many years compared to NoSQL database that are more suitable for
unstructured data.

But that's right, it's just matter of time and implementation to use
relational DBs as credential store for KDC.

Regards
Ali


On 2015-02-17 23:44, Nico Williams wrote:

> On Thu, Feb 12, 2015 at 06:54:18PM +0100, Ali Gholami wrote:
>> I wonder if there is any relational database compatibility with
>> Heimdal to store principals and credentials. I know there is LDAP
>> support for Heimdal but that causes overhead for enterprises to
>> adapt MySQL to support LDAP. For instance user management in LDAP
>> through command-line or synchronizing MySQL and LDAP server together
>> causes usability in many enterprise applications.
> If you mean the KDC-side database, yes, there's no reason that you
> couldn't store it in any DB you like.
>
> There have been two types thus far in actual implementations:
>
>   - key/value store, with the key being the principal name and the value
>     being an encoding of a complex data structure that includes keying
>     material;
>
>   - some DB technology, generally LDAP.
>
> LDAP is supported by Heimdal and MIT Kerberos, and something close to it
> is used by Microsoft's Active Directory.
>
> How much the LDAP server backend normalizes the data or not is an
> implementation detail.  LDAP does not fully specify backend database
> semantics (e.g., referential integrity), but implementors generally
> provide some such semantics.
>
> There is no reason at all that you couldn't use a relational backend.
>
> The main issue is how to interface with the KDC.  For existing KDCs your
> only choices would be: synchronize to the key/value KDB, or expose an
> LDAP interface.  For Heimdal and MIT a third choice would be to
> implement a backend that talks to your DB however you like.
>
>> I think it might be very useful to have such compatibility for
>> Kerberos to store user credentials in MySQL backend. This makes many
>> existing applications to use Kerberos services easily without the
>> need of deploying LDAP services.
> Normalizing the KDB has some administrative benefits.  It slows down
> reads unless you have triggers (or application-level equivalents) to
> keep denormalized views in sync.
>
>> I could not find any useful document ion for this problem. Is it
>> intentionally Heimdal does not support MySQL(or any relational
>> database) as backend or it's just a missing feature?
> Heimdal's interface to the HDB is very much key/value-like, but the LDAP
> backend scatter/gathers the value to/from the LDAP object attributes.
> The same approach should work for any other DB.
>
> I've toyed before with extending the Heimdal ASN.1 compiler to support
> extensions (semantic extensions, not syntactic ones!) for expressing
> mappings to relational (or LDAP) interfaces, so that more of the LDAP
> backend and/or a future SQL backend could be generated by the compiler.
> But I've never had time to follow through.
>
> Nico

Reply | Threaded
Open this post in threaded view
|

Re: MySQL as credential store in Heimdal

Jeffrey Altman-2
On 2/17/2015 6:38 PM, Ali Gholami wrote:

> Using relational databases as backend of KDC in some ways provides more
> convenient integration of Kerbeors with applications. Since many people
> are familiar with SQL and also relational databases have been around for
> many years compared to NoSQL database that are more suitable for
> unstructured data.

Ali,

The point that others have tried to make is the following

 The Kerberos Database only has one application, the KDC.

No other applications have any business touching the Kerberos database.

Sincerely,

Jeffrey Altman



smime.p7s (6K) Download Attachment
123