[midPoint] One connector for separate accounts on many Unix systems
Radovan Semancik
radovan.semancik at evolveum.com
Mon Nov 23 10:21:27 CET 2015
For the record: creating 400 resource definitions is really not that
hard. But it is much harder to maintain them. E.g. midPoint GUI will not
work well with 400 similar resource. Therefore we also have
https://jira.evolveum.com/browse/MID-2521
If you need to do something about that there are the usual options:
https://wiki.evolveum.com/display/midPoint/I+Need+New+Feature
--
Radovan Semancik
Software Architect
evolveum.com
On 11/19/2015 07:41 PM, Devin Rosenbauer wrote:
> That could work. I'd still like to avoid creating several hundred
> resource definitions just for Unix, if I can avoid it. We've seen
> clients with that many individually controlled Unix systems in
> Production. However, since it's easy enough to script creating 400
> resource definitions with the hostname configurations, the template
> model would definitely work for now.
>
>
> On Thu, Nov 19, 2015 at 1:22 PM, Radovan Semancik
> <radovan.semancik at evolveum.com <mailto:radovan.semancik at evolveum.com>>
> wrote:
>
> I'm not sure what you mean by "connector's
> connection-configuration info". If you mean connector
> configuration parameters (the <connectorConfiguration> part) then
> the answer is no. This is limited by the design of ConnId (which
> is based on Sun Identity Connectors). Only primitive values can be
> used there.
>
> So the multi-resource feature needs to be implemented inside
> midPoint. What we plan if having something like "resource
> templates" that can hold parameters common for all similar
> resources. Then the actual resource definition will have just the
> special parameters (hostname, admin password) and the generic
> parameters and configurations will be taken from the template. See
> https://jira.evolveum.com/browse/MID-1653
>
> --
> Radovan Semancik
> Software Architect
> evolveum.com <http://evolveum.com>
>
>
>
> On 11/19/2015 07:17 PM, Devin Rosenbauer wrote:
>> Is it possible to define a complex configuration type for a
>> connector's connection-configuration info? Or is that restricted
>> to strings and other simple types? If so, it would be easy enough
>> to create a nested connection info like this:
>>
>> <s:hosts>
>> <s:host name="whatever1">
>> <s:details/>
>> </s:host>
>> <s:host name="whatever2">
>> <s:details/>
>> </s:host>
>> </s:hosts>
>>
>> And have the connector decide up which host info to use at an ICF
>> level.
>>
>> Problem then, of course, is that you're passing around dozens of
>> credentials with every connector call.
>>
>> On Thu, Nov 19, 2015 at 1:13 PM, Radovan Semancik
>> <radovan.semancik at evolveum.com
>> <mailto:radovan.semancik at evolveum.com>> wrote:
>>
>> Hi,
>>
>> No, currently there is no easy way to do this. But you are
>> not the first one to request this and such a feature is
>> planned. All that is needed is that some midPoint
>> subscriber/contributor/sponzor explicitly requests it so the
>> priority of this feature is increased.
>>
>> --
>> Radovan Semancik
>> Software Architect
>> evolveum.com <http://evolveum.com>
>>
>>
>>
>> On 11/19/2015 07:00 PM, Devin Rosenbauer wrote:
>>> I'm curious if there's a clean way to do this in Midpoint. I
>>> have some ideas but don't want to reinvent the wheel if this
>>> sort of thing already exists.
>>>
>>> I've got a demo setup with ten different Unix systems which
>>> are authenticated locally. I would like to be able to
>>> provision an identical account to any / all of this Unix
>>> systems without creating ten identical connectors,
>>> replicating configuration, etc. That's just asking for
>>> misconfiguration disasters down the line.
>>>
>>> Is there a good Midpoint-y way to do this? Is there a good
>>> way to store the admin credentials separately for each of
>>> the ten hosts without making separate connectors?
>>>
>>> --
>>> Devin Rosenbauer
>>> Principal Consultant
>>> Identity Works LLC
>>> +1 585 210 3201 <tel:%2B1%20585%20210%203201>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> --
>> Devin Rosenbauer
>> Principal Consultant
>> Identity Works LLC
>> +1 585 210 3201 <tel:%2B1%20585%20210%203201>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> --
> Devin Rosenbauer
> Principal Consultant
> Identity Works LLC
> +1 585 210 3201
>
>
> _______________________________________________
> 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/20151123/ce11ab63/attachment.htm>
More information about the midPoint
mailing list