[midPoint] Synchronizing Encrypted User Password
Radovan Semancik
radovan.semancik at evolveum.com
Thu Sep 15 13:35:31 CEST 2016
On 09/14/2016 11:34 PM, pdbogen at cernu.us wrote:
> Understood. A small sponsorship _may_ be possible, but I'm sure I'll
> need a
> functional system to make any kind of case for it. In the mean time, I might
> be able to make some small code contributions if I find an opportunity.
Even a small sponsorship may be good enough to adjust the priorities in
this case. This is something that I personally consider to be a problem.
All I need is some justification or incentive (read: "excuse") to sit
down and implement it as soon as possible :-)
>
> This may be where I was overthinking it- I want to store the midpoint
> encrypted password in LDAP, so on initial synchronization, when I create users
> from LDAP accounts, those users will already have midpoint passwords set. I
> did not, however, want to store the password in LDAP unencrypted.
Oh, that may be tricky. If something is ProtectedString then midPoint
assumes that it is in fact a clear value in the resoruces. And it
converts it automatically. So you will not get the XML form of the
ProtectedString to any resource in any straightforward way because
midPoint will always convert it on input and output.
What you need is to explicitly convert ProtectedString to string in one
of the mappings. But you do not want to use getClearValue() or anything
like that, because that will produce cleartext value and not XML as you
would like.
And there is additional trouble: XML is just one of the representation
formats. It is the only one that midPoint supports, but not the only one
possible (e.g. in midPoint 3.5 there will be JSON and YAML). We have
expected that and the data and NOT represented in the XML form when they
are passed inside midPoint. They have native Java representation (e.g.
ProtectedStringType Java class). MidPoint serializes and deserializes
that automatically on the "ends" of the system. But inside midPoint core
the data are not XML. (This is slightly simplified explanation, but I
think it describes the situation well).
So, to get a XML representation of the ProtectedString you have to
explicitly serialize it. And there is no ProtectedString method to do
that, because there may be many supported formats in the future and we
do not want to have method for each format in each object. So you need
to invoke a XML serializer and pass the ProtectedString value to it. I
do not think that currently there is any easy way how to do this.
Honestly I haven't expected anyone to use it like this :-)
I could probably figure something out. But it may take several hours and
I'm afraid I do not have that time right now. Maybe you can a look at
the code yourself. And maybe one of my colleagues will have some idea
how to do this reasonably easily.
>
>> $user/credentials/password/value is ProtectedString. And that is
>> serializable. So if you define your encryptedPassword as
>> ProtectedStringType then all you need is to copy the whole
>> $user/credentials/password/value.
> Here's the error I get when I just do a plain:
>
> <attribute>
> <ref>ri:encryptedPassword</ref>
> <outbound><source><path>$user/credentials/password/value</path></source></outbound>
> <inbound><target><path>$user/credentials/password/value</path></target></inbound>
> </attribute>
>
> Upon attempting to change a User password:
>
> java.lang.IllegalArgumentException: Expected class [B type, but got class java.lang.String in outbound mapping for {.../resource/instance-3}encryptedPassword in resource:2a7c7130-7a34-11e4-bdf6-001e8c717e5b(OpenLDAP)
I would guess that you have defined encryptedPassword as binary
attribute (hence the [B which is Byte[]) and you are trying to store
String in it. If the midPoint property type is ProtectedString it will
be interpreted as String when it is decrypted. This is maybe one bug as
the mapping code should convert the data types automatically. Maybe you
can try to change the encryptedPassword attribute definition to string
just to see if it works. But I expect that it will end up with cleartext
value stored in the attribute, not the encrypted version.
--
Radovan Semancik
Software Architect
evolveum.com
More information about the midPoint
mailing list