[IdP] Bug fixes for 3.5.1

[IdP] Bug fixes for 3.5.1

  
Forge Component
(26)
Published on 4 Jul by Telmo Martins
26 votes
Published on 4 Jul by Telmo Martins

Greetings,

We recently updated IdP connector version to 3.5.1 in our system. Testing of this new version revealed a couple of issues that we had to patch ourselves. I would like you to consider inclusion of these fixes to trunk also. That way others could also benefit from our work, and we would have easier time updating IdP version in the future.

Espace file with the fixes is attached. The list of changes we did is as follows:

  1. In GetConfig action, set _TenantId_ of returned values also in case where the tenant did not have any existing configuration. This problem surfaced in our test automation, where test tenants do not always have any configuration defined before get is attempted.
  2. Make GenerateNewKeyStore action public. Needed for test automation that interacts with IdP module.
  3. Change IdPTenantSwitch action to set cookie also when tenant switch is not needed. It is possible to reach this code with tenant already correctly set. The cookie is needed even in that case, this fix ensures it is always set.
  4. Change attribute InternalConfiguration.AutoUserProvision default value to False. This is safer the option, auto provision is not always wanted and having it accidentally on may open the system for users that should not be let in.

Regards,
Otto Urpelainen
Enoro Oy

Hi Otto,

Thanks for your feedback.

1) If no configuration was found/created for that tenant the output records fields are empty as expected.... Your automated tests should handle that situation, not IdP side.

2) Sure, not a problem.

3) Actually the cookie is deprecated as the setCookie should be removed in the future.

4) From my experience with many OS customers that already have IdP on they ecosystem, that property should remain True as default. Who does not want auto provision, then should set it to False.


Regards.

Hi Telmo,

About item 1: this problem actually is related to action SetConfig. Our test case calls that action to set the required configurations. However, even though the caller has tenant_id properties set for all entities they get emptied when the GetConfig returns empty structures since SetConfig is not filling them with the incoming tenant_ids.

Otto thought the better spot to populate the tenant_ids would be GetConfig, but if not, could you fix the code to populate them in SetConfig instead?

Br,

Toni Juvani

Enoro Oy

Hi Toni,

Yes, completely agree. It should be fixed on SetConfig action instead. Probably when the tenantId was exposed I forgot to update SetConfig assigns to be compliant with that.

Thanks.

Greetings Telmo,

As far as I can tell, fixing SetConfig directly and leaving GetConfig as it is will resolve our problem.

Regards,
Otto

Hi Otto,

Sure, agree. As that action actually will also have a few more optional parameters for a new feature, but which defaults values will not change the current behavior of it.

Regards