[midPoint] midPoint Digest, Vol 62, Issue 7

Stumpf Alexander Alexander.Stumpf at zeta.com
Thu Jun 8 19:58:21 CEST 2017


Hi Martin,

thank you very much for your answers!

The outbound mapping with the strength definition works great! 
In the meantime I found a second solution: In the connector, every boolean "access right" on the resource is mapped to an entry in a multivalue for the connector object. The goal was creating an association in midpoint, but it failed because I could not get an association between two entitlements. But I can insert or remove an entry in this mutlivalue via role inducement. Works for me too. Is it possible, that entitlements cannot have entitlement assoc.?

Your idea with combining account and user seems interesting. I have to think about that. I am afraid the user right database is too complex, like MS things always are.... The account connects more users(for different companies), the account has separate permission sets and a profile, the users has separate permission sets... So I have to overthink my connector architecture if we eventually decide to use midpoint in our company.

Regards
Alex

B.Sc. Alexander Stumpf
System Development

ZETA Automation GmbH
Münchner Str. 8, D-85354 Freising
P +49 (8161) 99 21-649
F +49 (8161) 99 21-644
alexander.stumpf at zeta.com
http://www.zeta-automation.de

HRB 115294, Amtsgericht München; UST-Id. Nr. DE 189564479,
Geschäftsführung: Mag. René Haas, Dipl.-Ing. Dr. Andreas Marchler


:Disclaimer:

The information contained in this e-mail and in any attached files is confidential and/or legally privileged. If you are not the intended recipient, please contact the sender and delete this e-mail. Any unauthorised copying or distribution of the information contained in this e-mail and/or in any attached file is prohibited. The sender and/or the sending company do not accept liability for the incorrect and/or incomplete transmission of the information, nor for any delay or interruption of the transmission, nor for the damages arising from the use of or reliance on the information unless mandatory law provides otherwise. E-mails may be interfered with, may contain computer viruses or other defects. The sender and/or the sending company give no warranties and do not accept liability in relation to these matters, unless mandatory law provides otherwise. Thank you for your cooperation.

-----Ursprüngliche Nachricht-----
Von: midPoint [mailto:midpoint-bounces at lists.evolveum.com] Im Auftrag von midpoint-request at lists.evolveum.com
Gesendet: Mittwoch, 07. Juni 2017 21:11
An: midpoint at lists.evolveum.com
Betreff: midPoint Digest, Vol 62, Issue 7

Send midPoint mailing list submissions to
	midpoint at lists.evolveum.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.evolveum.com/mailman/listinfo/midpoint
or, via email, send a message with subject or body 'help' to
	midpoint-request at lists.evolveum.com

You can reach the person managing the list at
	midpoint-owner at lists.evolveum.com

When replying, please edit your Subject line so it is more specific than "Re: Contents of midPoint digest..."


Today's Topics:

   1. Re: Configuration of Entitlements (Stumpf Alexander)
      (Martin Lízner - AMI Praha a.s.)
   2. Re: Configuration of Entitlements
      (Martin Lízner - AMI Praha a.s.)


----------------------------------------------------------------------

Message: 1
Date: Wed, 7 Jun 2017 21:03:52 +0200
From: Martin Lízner - AMI Praha a.s.  <martin.lizner at ami.cz>
To: midPoint General Discussion <midpoint at lists.evolveum.com>
Subject: Re: [midPoint] Configuration of Entitlements (Stumpf
	Alexander)
Message-ID:
	<CALOh8eNs1qXtXtZYxi8ujbsMzJJnO3Wu6CSX_e3iuWjJtKfGsQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi, well.. could you set role outbound to strength normal? Then you can set weak outbound on same attribute on resource level. M.

Martin Lízner
solution architect

gsm: [+420] 737 745 571 <+420%20737%20745%20571>
e-mail: martin.lizner at ami.cz


AMI Praha a.s.
Pláničkova 11
162 00 Praha 6
tel.: [+420] 274 783 239 <+420%20274%20783%20239>
web: www.ami.cz



[image: AMI Praha a.s.] <http://www.skyidentity.com/>

Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.


2017-06-07 10:23 GMT+02:00 Stumpf Alexander <Alexander.Stumpf at zeta.com>:

> Hello Midpoint Team,
>
>
>
> I have finally achieved to create a setup with midpoint that works 
> with my connector. It is not best practice, but it works for the 
> moment and is sufficient.
>
>
>
> One Topic is left:
>
> I want to set one (or more) Boolean(s) in a table depending on a 
> role-ownership.
>
> If a user is assigned to the role, the Boolean should be true, if I 
> remove the role, the Boolean should be false.
>
>
>
> I can set the Boolean using Inducement on the role (I use weak 
> strength on
> purpose)
>
>>
> <inducement id=”x”>
>
>                 <!— resource ref, Kind, intent a so on … -->
>
>
>
>                 <attribute>
>
>                                <c:ref>myBooleanAttribute<c:ref>
>
>                                <outbound>
>
>                                                <expression>
>
>
> <value>true</value>
>
>                                                </expression>
>
>                                </outbound>
>
>                 </attribute>
>
>                 <strength<weak</strength>
>
> </inducement>
>
>
>
> When the role is assigned, “myBooleanAttribute” is set to true, like 
> expected and wanted.
>
>
>
> How can I set the attribute to “false” when the role is removed.
>
> Has this something to do with the delta mechanism? I have not found 
> any
> “trigger: Deprovisioning Role” where I can set the Boolean to false.
>
> Is there any? I know, I have to consider Role explosion, SOD  and 
> policies, when applying such a rule.
>
>
>
> I would be very happy, if anyone could help me with this matter.
>
> Thank you in advance an best regards
>
>
>
> Alex
>
>
>
>
>
> B.Sc. Alexander Stumpf
>
> System Development
>
>
>
> *ZETA Automation GmbH*
>
> Münchner Str. 8, D-85354 Freising
>
> P +49 (8161) 99 21-649 <+49%208161%209921649>
>
> F +49 (8161) 99 21-644 <+49%208161%209921644>
>
> alexander.stumpf at zeta.com
>
> *http://www.zeta-automation.de <http://www.zeta-automation.de/>*
>
>
>
> HRB 115294, Amtsgericht München; UST-Id. Nr. DE 189564479,
> Geschäftsführung: Mag. René Haas, Dipl.-Ing. Dr. Andreas Marchler
>
>
>
>
>
>
> *:Disclaimer: *
> The information contained in this e-mail and in any attached files is 
> confidential and/or legally privileged. If you are not the intended 
> recipient, please contact the sender and delete this e-mail. Any 
> unauthorised copying or distribution of the information contained in 
> this e-mail and/or in any attached file is prohibited. The sender 
> and/or the sending company do not accept liability for the incorrect 
> and/or incomplete transmission of the information, nor for any delay 
> or interruption of the transmission, nor for the damages arising from 
> the use of or reliance on the information unless mandatory law 
> provides otherwise. E-mails may be interfered with, may contain 
> computer viruses or other defects. The sender and/or the sending 
> company give no warranties and do not accept liability in relation to 
> these matters, unless mandatory law provides otherwise. Thank you for your cooperation.
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.evolveum.com/pipermail/midpoint/attachments/20170607/96be5f2d/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 7 Jun 2017 21:09:23 +0200
From: Martin Lízner - AMI Praha a.s.  <martin.lizner at ami.cz>
To: midPoint General Discussion <midpoint at lists.evolveum.com>
Subject: Re: [midPoint] Configuration of Entitlements
Message-ID:
	<CALOh8eOjbUJ=mfgi0RoUXQ06Q8TLAKOOKrACYBX_=3kQ4-VO1w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi, I dont know NAV, but midPoint is very strong at handling different object types on the resource. But Im not sure whether this is the right way here. If user and account represent the same entity on the resource, you should probably join them together into single entity with attributes.
Connector will contain the logic how to map this entity attributes to those two tables. M.

Martin Lízner
solution architect

gsm: [+420] 737 745 571
e-mail: martin.lizner at ami.cz


AMI Praha a.s.
Pláničkova 11
162 00 Praha 6
tel.: [+420] 274 783 239
web: www.ami.cz



[image: AMI Praha a.s.] <http://www.skyidentity.com/>

Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.


2017-06-06 9:46 GMT+02:00 Stumpf Alexander <Alexander.Stumpf at zeta.com>:

> Hello midpoint team,
>
>
>
> I started to create a Rest-based connector for Microsoft Dynamics NAV 
> 2015. My first approach is to connect two Object classes of NAV: “Account”
> and “User”.
>
> I managed to create and Connector with all CRUD operation and used 
> Testclasses to verify them successfully.
>
>
>
> But now I have a basic understanding problem in configure “Account and 
> entitlements” in midpoint and would like to know, what a good practice 
> could be.
>
>
>
> The tables in NAV are as follows:
>
> 1.       Account-table: A simple Account table with Identifier for user
>
> 2.       User-table: Connects the account Table 1 to specific company and
> to specific  Rights. It is like an Access Control List. Here an 
> example setup with columns
>
> a.       User_ID: String – The ID from “Account-Table”
>
> b.      CompanyName:String – a foreign key
>
> c.       RightNo1: Boolean
>
> d.      RightNo2: Boolean
>
> The cardinality is Account:User_ID (1 : N) User-table:User_ID, where 
> User_ID and CompanyName are a constraint key.
>
>
>
> Setting up the resource in Midpoint for the table “Account” was no 
> problem. The midpoint user is connected to the NAV account. CRUD 
> Operations work.
>
> But what is a good setup for the “User-Table”?
>
> The behaviour I want:
>
> -          When assigning a (company specific) role to a user, an entry
> in “User-Table”  is created (I think it is inducement – with generic
> construction)
>
> -          When assigning another role, a “Right”:Boolean is set.
>
> -          When the (company specific) role is removed, the entry in the
> “User-Table” should be deleted
>
> I already tried a dozen of setups (as entitlement, as Account, as 
> entitlement linked to user…, I do not want to write them all down, 
> assuming nobody will want to read the whole story) but I did not get by.
>
>
>
> One more Info: I have NOT set up an entitlement association yet, 
> because I have not programmed a multiValue field that could be used as 
> an “association field” yet. Should I, or can I use the “User_ID” field 
> of User-table?
>
>
>
> If you could give me any advice, I would be very happy.
>
> Thank you in advance
>
>
>
> Alex
>
>
>
>
>
> B.Sc. Alexander Stumpf
>
> System Development
>
>
>
> *ZETA Automation GmbH*
>
> Münchner Str. 8, D-85354 Freising
>
> P +49 (8161) 99 21-649 <+49%208161%209921649>
>
> F +49 (8161) 99 21-644 <+49%208161%209921644>
>
> alexander.stumpf at zeta.com
>
> *http://www.zeta-automation.de <http://www.zeta-automation.de/>*
>
>
>
> HRB 115294, Amtsgericht München; UST-Id. Nr. DE 189564479,
> Geschäftsführung: Mag. René Haas, Dipl.-Ing. Dr. Andreas Marchler
>
>
>
>
>
>
> *:Disclaimer: *
> The information contained in this e-mail and in any attached files is 
> confidential and/or legally privileged. If you are not the intended 
> recipient, please contact the sender and delete this e-mail. Any 
> unauthorised copying or distribution of the information contained in 
> this e-mail and/or in any attached file is prohibited. The sender 
> and/or the sending company do not accept liability for the incorrect 
> and/or incomplete transmission of the information, nor for any delay 
> or interruption of the transmission, nor for the damages arising from 
> the use of or reliance on the information unless mandatory law 
> provides otherwise. E-mails may be interfered with, may contain 
> computer viruses or other defects. The sender and/or the sending 
> company give no warranties and do not accept liability in relation to 
> these matters, unless mandatory law provides otherwise. Thank you for your cooperation.
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.evolveum.com/pipermail/midpoint/attachments/20170607/0bd03ba2/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
http://lists.evolveum.com/mailman/listinfo/midpoint


------------------------------

End of midPoint Digest, Vol 62, Issue 7
***************************************


More information about the midPoint mailing list