[keycloak-dev] Storage protection

[Bill Burke]

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.

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?")


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com