You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Denis Signoretto <de...@intesys.it> on 2013/01/09 13:02:20 UTC
Support for encripted schema attributes
Hi Syncopers,
At the moment, for our purpose, it's not a actual requirement.
I'm wondering if in the roadmap could be added a schema attribute
which Syncope stores encrypted so neither the administrator can view the real value.
WDYT ?
Regards,
Denis.
<http://www.intesys.it/firme/logo_intesys.jpg>
Denis Signoretto | Senior Project Manager
Intesys - Via Roveggia 122 A - 37136 Verona
Tel. 045 503663 | Fax 045 503604
denis.signoretto@intesys.it
www.intesys.it <http://www.intesys.it/>
Le informazioni contenute nella presente e-mail e nei suoi allegati potrebbero essere confidenziali/riservate e sono dirette unicamente ai destinatari sopra indicati. In caso di ricezione da parte di persona diversa è vietato qualunque tipo di divulgazione o copia anche parziale. Chi riceva questo messaggio per errore è pregato di inoltrarlo al mittente e di cancellare questa e-mail.
This e-mail and its attachments may contain confidential/reserved information and is intended only for the use of the address(es) named above. If the reader of this message is not the intended recipient of this message, please note that distribution or copying of this communication is forbidden. Anyone who receives this communication in error should return it immediately to the sender and delete the message.
Re: Support for encrypted schema attributes
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/01/2013 11:48, Andrei Shakirin wrote:
> Sounds reasonable for me, two additional questions:
>
> 1) Does it make sense optionally to support storing only hash value of passphrase and not passphrase itself?
Yes, definitely: in the summary below, this is implied when you selected
an hashing algorithm.
> 2) Any plans to store X509 certificates?
Yes, again: check SYNCOPE-123 (and related e-mail thread).
Regards.
>> -----Original Message-----
>> From: Francesco Chicchiriccò [mailto:ilgrosso@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/
RE: Support for encrypted schema attributes
Posted by Andrei Shakirin <as...@talend.com>.
Sounds reasonable for me, two additional questions:
1) Does it make sense optionally to support storing only hash value of passphrase and not passphrase itself?
2) Any plans to store X509 certificates?
Regards,
Andrei.
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@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/
Re: Support for encrypted schema attributes
Posted by Fabio Martelli <fa...@gmail.com>.
Il giorno 10/gen/2013, alle ore 10.01, Francesco Chicchiriccò ha scritto:
> 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.
Absolutely reasonable!
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>
Re: Support for encrypted schema attributes
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/01/2013 10:40, ernst Developer wrote:
> Hi Francesco,
> The list of requirements sounds reasonable. I have another question: where
> does Syncope store the encryption key?
Hi Ernst,
for user passwords - and as I wrote below, I am proposing to do the same
with passphrase encryption - the encryption key is barely and statically
defined in source code [1] for 1_0_X, [2] for trunk.
I haven't realized so far how this is bad: I'll open immediately an issue.
Regards.
[1]
http://svn.apache.org/repos/asf/syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/persistence/beans/user/SyncopeUser.java
[2]
http://svn.apache.org/repos/asf/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/PasswordEncoder.java
> 2013/1/10 Francesco Chicchiriccò <il...@apache.org>
>
>> 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/
Re: Support for encrypted schema attributes
Posted by ernst Developer <er...@gmail.com>.
Hi Francesco,
The list of requirements sounds reasonable. I have another question: where
does Syncope store the encryption key?
Regards,
Ernst
2013/1/10 Francesco Chicchiriccò <il...@apache.org>
> 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/<http://people.apache.org/~ilgrosso/>
>
>
R: Support for encrypted schema attributes
Posted by Denis Signoretto <de...@intesys.it>.
+1
Agree with Jan. Nice summary :)
Regards.
Denis
> -----Messaggio originale-----
> Da: Jan Bernhardt [mailto:jbernhardt@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:ilgrosso@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/
>
>
RE: Support for encrypted schema attributes
Posted by Jan Bernhardt <jb...@talend.com>.
+1
Nice summary!
Regards.
Jan
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@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/
Re: Support for encrypted schema attributes
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
R: Support for encripted schema attributes
Posted by Denis Signoretto <de...@intesys.it>.
> -----Messaggio originale-----
> Da: Fabio Martelli [mailto:fabio.martelli@gmail.com]
> Inviato: mercoledì 9 gennaio 2013 17:21
> A: dev@syncope.apache.org
> Oggetto: Re: Support for encripted schema attributes
>
>
>
> Il giorno 09/gen/2013, alle ore 14.23, Jan Bernhardt ha scritto:
>
> > Hi Denis,
> >
> > who will be the owner of the private key, and why does
> syncope needs to know that the value inside a field is encrypted?
> >
> > If syncope does not have a key to decrypt the value, then
> syncope does not even need to know that this field is
> encrypted is simply a BASE64 encoded String (for example).
> >
> > So from my point of view the only usecase that actually
> would make sense for such a schema attribute, is if syncope
> knows the private key (properly generated that key) and the
> goal is to store encrypted values in a remote system. But why
> storing information in a remote system, if that system should
> not be able to read this information?
> >
> > So at this point I can't see a real usecase that would
> actually benefit from such an attribute. Can you provide an
> example please.
>
> Agree, probably this feature is not so useful BTW it could be
> interesting.
> Actually, in the past I have had some experience with
> encrypted attribute values.
>
> +1 to implement this feature.
> Anyway, I'm looking forward to read a possible use case from Denis.
>
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).
> @Francesco, I think that this attribute should be visible on
> the console if and only if
> 1. is encrypted using a reversible algorithm
> 2. the owner specify it explicitly
> In any case, its propagation should be encrypted.
>
> Regards,
> F.
>
> > Best regards
> > Jan
> >
> >> -----Original Message-----
> >> From: Denis Signoretto [mailto:denis.signoretto@intesys.it]
> >> Sent: Mittwoch, 9. Januar 2013 13:02
> >> To: dev@syncope.apache.org
> >> Subject: Support for encripted schema attributes
> >>
> >> Hi Syncopers,
> >>
> >> At the moment, for our purpose, it's not a actual requirement.
> >>
> >> I'm wondering if in the roadmap could be added a schema
> attribute which
> >> Syncope stores encrypted so neither the administrator can
> view the real
> >> value.
> >>
> >> WDYT ?
> >>
> >> Regards,
> >> Denis.
> >>
> >> <http://www.intesys.it/firme/logo_intesys.jpg>
> >>
> >> Denis Signoretto | Senior Project Manager
> >>
> >> Intesys - Via Roveggia 122 A - 37136 Verona Tel. 045
> 503663 | Fax 045 503604
> >> denis.signoretto@intesys.it www.intesys.it <http://www.intesys.it/>
> >>
> >> Le informazioni contenute nella presente e-mail e nei suoi allegati
> >> potrebbero essere confidenziali/riservate e sono dirette
> unicamente ai
> >> destinatari sopra indicati. In caso di ricezione da parte
> di persona diversa è
> >> vietato qualunque tipo di divulgazione o copia anche
> parziale. Chi riceva
> >> questo messaggio per errore è pregato di inoltrarlo al
> mittente e di cancellare
> >> questa e-mail.
> >>
> >> This e-mail and its attachments may contain confidential/reserved
> >> information and is intended only for the use of the
> address(es) named
> >> above. If the reader of this message is not the intended
> recipient of this
> >> message, please note that distribution or copying of this
> communication is
> >> forbidden. Anyone who receives this communication in error
> should return it
> >> immediately to the sender and delete the message.
> >>
> >>
>
>
Re: Support for encripted schema attributes
Posted by Fabio Martelli <fa...@gmail.com>.
Il giorno 09/gen/2013, alle ore 14.23, Jan Bernhardt ha scritto:
> Hi Denis,
>
> who will be the owner of the private key, and why does syncope needs to know that the value inside a field is encrypted?
>
> If syncope does not have a key to decrypt the value, then syncope does not even need to know that this field is encrypted is simply a BASE64 encoded String (for example).
>
> So from my point of view the only usecase that actually would make sense for such a schema attribute, is if syncope knows the private key (properly generated that key) and the goal is to store encrypted values in a remote system. But why storing information in a remote system, if that system should not be able to read this information?
>
> So at this point I can't see a real usecase that would actually benefit from such an attribute. Can you provide an example please.
Agree, probably this feature is not so useful BTW it could be interesting.
Actually, in the past I have had some experience with encrypted attribute values.
+1 to implement this feature.
Anyway, I'm looking forward to read a possible use case from Denis.
@Francesco, I think that this attribute should be visible on the console if and only if
1. is encrypted using a reversible algorithm
2. the owner specify it explicitly
In any case, its propagation should be encrypted.
Regards,
F.
> Best regards
> Jan
>
>> -----Original Message-----
>> From: Denis Signoretto [mailto:denis.signoretto@intesys.it]
>> Sent: Mittwoch, 9. Januar 2013 13:02
>> To: dev@syncope.apache.org
>> Subject: Support for encripted schema attributes
>>
>> Hi Syncopers,
>>
>> At the moment, for our purpose, it's not a actual requirement.
>>
>> I'm wondering if in the roadmap could be added a schema attribute which
>> Syncope stores encrypted so neither the administrator can view the real
>> value.
>>
>> WDYT ?
>>
>> Regards,
>> Denis.
>>
>> <http://www.intesys.it/firme/logo_intesys.jpg>
>>
>> Denis Signoretto | Senior Project Manager
>>
>> Intesys - Via Roveggia 122 A - 37136 Verona Tel. 045 503663 | Fax 045 503604
>> denis.signoretto@intesys.it www.intesys.it <http://www.intesys.it/>
>>
>> Le informazioni contenute nella presente e-mail e nei suoi allegati
>> potrebbero essere confidenziali/riservate e sono dirette unicamente ai
>> destinatari sopra indicati. In caso di ricezione da parte di persona diversa è
>> vietato qualunque tipo di divulgazione o copia anche parziale. Chi riceva
>> questo messaggio per errore è pregato di inoltrarlo al mittente e di cancellare
>> questa e-mail.
>>
>> This e-mail and its attachments may contain confidential/reserved
>> information and is intended only for the use of the address(es) named
>> above. If the reader of this message is not the intended recipient of this
>> message, please note that distribution or copying of this communication is
>> forbidden. Anyone who receives this communication in error should return it
>> immediately to the sender and delete the message.
>>
>>
RE: Support for encripted schema attributes
Posted by Jan Bernhardt <jb...@talend.com>.
Hi Denis,
who will be the owner of the private key, and why does syncope needs to know that the value inside a field is encrypted?
If syncope does not have a key to decrypt the value, then syncope does not even need to know that this field is encrypted is simply a BASE64 encoded String (for example).
So from my point of view the only usecase that actually would make sense for such a schema attribute, is if syncope knows the private key (properly generated that key) and the goal is to store encrypted values in a remote system. But why storing information in a remote system, if that system should not be able to read this information?
So at this point I can't see a real usecase that would actually benefit from such an attribute. Can you provide an example please.
Best regards
Jan
> -----Original Message-----
> From: Denis Signoretto [mailto:denis.signoretto@intesys.it]
> Sent: Mittwoch, 9. Januar 2013 13:02
> To: dev@syncope.apache.org
> Subject: Support for encripted schema attributes
>
> Hi Syncopers,
>
> At the moment, for our purpose, it's not a actual requirement.
>
> I'm wondering if in the roadmap could be added a schema attribute which
> Syncope stores encrypted so neither the administrator can view the real
> value.
>
> WDYT ?
>
> Regards,
> Denis.
>
> <http://www.intesys.it/firme/logo_intesys.jpg>
>
> Denis Signoretto | Senior Project Manager
>
> Intesys - Via Roveggia 122 A - 37136 Verona Tel. 045 503663 | Fax 045 503604
> denis.signoretto@intesys.it www.intesys.it <http://www.intesys.it/>
>
> Le informazioni contenute nella presente e-mail e nei suoi allegati
> potrebbero essere confidenziali/riservate e sono dirette unicamente ai
> destinatari sopra indicati. In caso di ricezione da parte di persona diversa è
> vietato qualunque tipo di divulgazione o copia anche parziale. Chi riceva
> questo messaggio per errore è pregato di inoltrarlo al mittente e di cancellare
> questa e-mail.
>
> This e-mail and its attachments may contain confidential/reserved
> information and is intended only for the use of the address(es) named
> above. If the reader of this message is not the intended recipient of this
> message, please note that distribution or copying of this communication is
> forbidden. Anyone who receives this communication in error should return it
> immediately to the sender and delete the message.
>
>
R: Support for encripted schema attributes
Posted by Denis Signoretto <de...@intesys.it>.
> -----Messaggio originale-----
> Da: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> Inviato: mercoledì 9 gennaio 2013 14:01
> A: dev@syncope.apache.org
> Oggetto: Re: Support for encripted schema attributes
>
>
> On 09/01/2013 13:02, Denis Signoretto wrote:
> > Hi Syncopers,
> >
> > At the moment, for our purpose, it's not a actual requirement.
> >
> > I'm wondering if in the roadmap could be added a schema attribute
> > which Syncope stores encrypted so neither the administrator
> can view the real value.
> >
> > WDYT ?
>
> Hi Denis,
> it seems a nice idea, indeed.
> I'd schedule an "Encrypted schema" for 1.2.0, alongside with
> SYNCOPE-123
> (Binary schema).
>
> Is it correct to say that we are talking about a schema whose
> attribute
> values are stored encrypted in the underlying database and decrypted
> during read?
> I imagine, in fact, that transfer objects (UserTO, RoleTO and
> MembershipTO) will contain such values as cleartext anyway...
Yes,
maybe through GuardedString Java object like password implementation.
Moreover, it could be desiderable the possibility to choose
if their content should be visible in the administration console.
Regards.
Denis
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>
>
Re: Support for encripted schema attributes
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 09/01/2013 13:02, Denis Signoretto wrote:
> Hi Syncopers,
>
> At the moment, for our purpose, it's not a actual requirement.
>
> I'm wondering if in the roadmap could be added a schema attribute
> which Syncope stores encrypted so neither the administrator can view the real value.
>
> WDYT ?
Hi Denis,
it seems a nice idea, indeed.
I'd schedule an "Encrypted schema" for 1.2.0, alongside with SYNCOPE-123
(Binary schema).
Is it correct to say that we are talking about a schema whose attribute
values are stored encrypted in the underlying database and decrypted
during read?
I imagine, in fact, that transfer objects (UserTO, RoleTO and
MembershipTO) will contain such values as cleartext anyway...
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/