[midPoint] SSO, passwords, and end users

[Florin. Stingaciu]

>
> Yes. If you set up authorizations in a proper way then the GUI should
> adapt.


I'll try looking into this, however I'm not really sure how to set GUI
authorization rules for the midPoint repository. Also, I'd only wanna hide
these two resources for the GUI credentials page only.


> But easier way would be to set up fixed (strong) mappings for password
> propagation and completely disallow account changes.


I agree, however currently we don't story any passwords in the midPoint
repository as per the security standards of this department. So
unfortunately this is not an option for us.

Thanks for the thorough explanation. In the near future, I'll attempt to
craft a feature request for this particular issue.

As an alternative to this whole situation, we've built a separate custom
web component that directly edits the LDAP attribute for a particular user.
It would be ideal to integrate this web component directly in midPoint. Are
there any instructions (besides just hacking it) on how to add a custom web
component to midPoint such that it respects authentication and such?

Thanks,
-F

On Mon, Jul 18, 2016 at 10:35 AM, Radovan Semancik <
radovan.semancik at evolveum.com> wrote:

> Hi,
>
> On 07/18/2016 06:54 PM, Florin. Stingaciu wrote:
>
>> So I managed to resolve the "Old Password" input field on the credentials
>> page, however the password propagation for the midPoint repository resource
>> is enabled by default. Is there anyway to specify one particular resource
>> to be enabled by default? We want to avoid storing any passwords on the
>> midPoint DB at all costs.
>>
>
> I think there is a way to hide the password propagation dialog. Use the
> propagationUserControl setting (see the XSD schema or maybe one of my
> colleagues can provide an example).
> Then simply use password outbound mappings to propagate the password just
> to one resource.
>
> However, currently it is not easy to avoid storing password in midpoint
> database. MidPoint philosophy is to always synchronize between focus (user)
> and projection (account) and never between projections directly. So, the
> password needs to be present in midPoint user. And for now complete user is
> stored in the database.
>
> There was some discussion about the setting to store passwords in hashed
> form (as opposed to encrypted form as it is now). Or even to handle
> password only in memory and not to store it at all. I would really like to
> implement that - and I was expecting this flexibility during midPoint
> design, so the implmenetation should not be that difficult. But obviously
> this feature haven't attracted attention of any midPoint subscriber or
> sponsor. Therefore it is not implemented.
>
> If you want to avoid storing the password you can do some magic with
> scripting hook and remove the password from the user and user deltas at the
> right moment in the request processing "clockwork": just after it was
> propagated to projection context but before the user is stored. I believe
> that this is possible, but it will require very clever manipulation of
> model context.
>
> ... or you can get a subscription or sponsor this feature.
>
> In total we have three repositories. One for the midPOint repository, an
>> LDAP server (which is where we want to change passwords by default) and
>> lastly there's a read only Active Directory. Is there any way (either via
>> security policies, or the authorization model) to only show and allow
>> password changes on the LDAP server?
>>
>
> Yes. If you set up authorizations in a proper way then the GUI should
> adapt. But easier way would be to set up fixed (strong) mappings for
> password propagation and completely disallow account changes.
>
> However, currently the GUI is designed to conveniently change only the
> user password. And we have no plans to extend that to account passwords as
> the common use case is to change user password and propagate the change to
> the resources. We do not want to confuse end user too much ... and in fact
> many users find the password propagation dialog too confusing, hence the
> option to disable it. So just one entry for the password should be enough.
> The way forward is to control the way how user password is stored in
> midpoint repository. I'm sorry that we do not have that yet. But anyone can
> help with funding of this feature.
>
> It could work like this:
>
> User changes his password in midPoint (already implemented)
> MidPoint will propagate the password to the resources using the mappings
> (already implemented)
> MidPoint consults the password storage policy and forgets the password
> (not implemented)
>
> So, just a little piece is missing.
>
>
> --
> Radovan Semancik
> Software Architect
> evolveum.com
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160718/165fd251/attachment.htm>