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
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
) but at the same
time, a file could have a very restricted access while the database is more acessible to
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?")
JBoss, a division of Red Hat