[keycloak-dev] Storage protection

[Anil Saldhana]

On 01/27/2014 09:53 AM, Bill Burke wrote:
>
> On 1/27/2014 10:28 AM, Anil Saldhana wrote:
>> It is going to be a choice between usability and protection.
>>
>> Security sensitive deployments are going to be using HSM and vaulted
>> networks.
>>
>> For everybody else, best is to go with usability thereby choosing an
>> approach that gives good-enough security.
>>
>> One of the challenges we have faced is the non-availability of a
>> database for default deployments and the use of filesystem as the
>> default mechanism for storage. In the case of KeyCloak, it is using the
>> DB as the storage mechanism.
>>
> I will throw out my red BS flag!...Can't see anybody seriously
> considering using a flat file for production systems.   There's no
> reason you can't have a local-only, locked down DB with either HQL,
> Mongo, or one of the other better Java databases.  But anyways, Keycloak
> only uses RDBMS by default, it has an SPI, and there's still the
> Picketlink IDM API option available to us which we're going to seriously
> consider after all major features have been implemented and we've
> planned comprehensively about federation and scalability.
Typically in production systems, the choice of storage is DB or LDAP. 
That is when a stronger strategy such as HSM (Hardware Security Module) 
is used.
http://en.wikipedia.org/wiki/Hardware_security_module

But for development purposes, a DB may not be available as the default 
mechanism.  In the case of WildFly AS, I am unsure if they ship with a 
default DB
anymore.

>
> More comments inline responding to Bruno's email:
>
>>> # 1
>>> - HSM or Java Security manager are perfect, but impractical for regular devs, that would require a lot of maintanance (a dream)
>>>
> What is HSM?  How could  the Java Security Manager protect clear text
> private keys and OTP keys?
>
>
>>> # 2
>>> - Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that someone would be required to enter the password at each app startup
>>>
>>> # 3
>>>
>>> - Not bullet-proof solution, but store the key into a text file that only sysadmins and the web server has access, doing our best with the usage of ACLs provided by environment.  I understand Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same time, a file could have a very restricted access while the database is more acessible to developers.
>>> -
>
> Stian suggested having an SPI for this sort of feature.  Either a
> password would be required at Keycloak server startup, or the password
> would be stored in a property file.
>
>>> # 4
>>>
>>> Generate the keys per session, instead of use it per realm (it must be tested/implemented because that could slow down our server)
>>>
> Not sure this is feasible.  In a clustered environment, you'd need a
> trusted way of transmitting all the realm keys.  You also would need a
> way to transmit the public key of the realm to each adapter.  Each
> adapter could make an HTTPS call on bootup to retrieve all relevant
> realm metadata, but you'd still have to provide a truststore for the
> adapter so it could make a trusted HTTPS call that verified the keycloak
> server's host.  But maybe we need this truststore irregardless :) ???
>
> But, this still doesn't protect clear text OTP keys (i.e. "What is your
> mother's maiden name?")
>
>