[midPoint] Synchronizing Encrypted User Password

[Radovan Semancik]

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