On 09/01/2013 19:37, Denis Signoretto wrote:
[...]
I agree with Fabio, probably this feature it's not so useful in most of common
cases.
I was imagining a general use cases where some user attributes, for security
reasons
or law restrictons, can't be stored cleartext; e.g. a sort of sencondary
password or
a PIN to use for instance to open doors or to enable a payment (some online
banking
use a secondary PIN to confirm a payment operation).
Hi all,
let me summarize the requirements of this new "Encrypted Schema" (for
what I have understood from recent e-mails).
1. Main purpose: store some arbitrary string values encrypted in the
database; this can be enforced by law, for example.
2. When defining an encrypted schema, you must provide the cypher
algorithm to be used and a passphrase.
Such passphrase will be stored by Syncope as encrypted with an internal
key (more or less like we are already doing with user passwords).
3. When creating an attribute with such schema, the value(s) will be
automatically encrypted by Syncope using the provided algorithm and
passphrase.
4. When reading an attribute with such schema (e.g. contained in an
AttributeTO), the value(s) will be sent encrypted.
Only who knows the algorithm and the passphrase will be able to decrypt.
Moreover, you can think to make the admin console able to show such
attribute value(s) as encrypted by default and to decrypt them on demand
after asking for algorithm and passphase.
5. When propagating / synchronizing attribute with such schema,
GuardedString will be used, not String.
6. When changing algorithm or passpshase of an existing schema, new
values will be encrypted with these, old values will remain as they are.
Naturally, one can provide an update procedure.
Does it sound reasonable? If so I will open an issue for this.
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
