+1 Agree with Jan. Nice summary :)
Regards. Denis > -----Messaggio originale----- > Da: Jan Bernhardt [mailto:jbernha...@talend.com] > Inviato: giovedì 10 gennaio 2013 11:24 > A: dev@syncope.apache.org > Oggetto: RE: Support for encrypted schema attributes > > > +1 > Nice summary! > > Regards. > Jan > > > -----Original Message----- > > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > > Sent: Donnerstag, 10. Januar 2013 10:01 > > To: dev@syncope.apache.org > > Subject: Re: Support for encrypted schema attributes > > > > 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/ > >
