IDB-355 initially required that connectors be disabled to be added to groups. It was decided that this requirement was silly to enforce as it didn't add anything to the solution and would require work in the future to maintain this restriction.

The changed requirement, however, was missed.

Attempting to add a "Copy" transformation that contains the default values

singleval insert into singleval

Results in a transformation that adds the same field twice to the adapter schema. The error message on the transformation though is as follows:

Specified argument was out of the range of valid values. Parameter name: key 

With some schema providers potentially having 100 fields, the ability to optionally select which fields are applied becomes quite important.

First determine the feasibility of this, and make sure it won't take much longer than the estimate before commencing.

Update the schema provider to have check-boxes next to each field (default checked) and only apply those that are checked. Also include a check all / uncheck all checkbox at the top.

Currently, When Group Membership information is read in via a transformation, if you write back to this attribute the data disappears into the ether, with no warning or errors thrown.

An error or warning should be thrown.

From UNISC-10, trailing spaces were causing issues with a join. The issue wasn't resolved until the connector was cleared and reimported. The trailing spaces should have been removed during regular connector imports. Investigate whether trailing spaces are detected as a change (and subsequently reflected), and also the scenario with the key only changing.

When attempted to request schema for the InnerRange Concept 4000 Virtual User connector I recieve the following error:

Value cannot be null. Parameter name: There are no known default validators that support the Byte value type. 

Observation

New position change through join transformation (relevant selection) were happening a day early.

The windows appear to be the only thing that uses the local flag. However, there is a fair bit of logic in the selections that should have the local flag applied. See RecentSelection, RelevantSelection and NextPlacementSelection.

Task

1. Create unit tests for all boundary conditions around date and time for the above mentioned selections.
2. Fix up broken unit tests.

This morning a PHRIS event occurred which resulted in the unwanted disabling of some 2K+ AD user accounts - see CSODBB-312.

The culprit turned out to be the nightly PHRIS practice of truncating the PERSON table at 3 AM, which had a knock-on effect of causing Identity Broker adapter DELETIONS of some 3.5K JOB records - by virtue of a SQL join on EMPLOYEE in the JOB view which is used within the PHRIS JOB web service method implementation.

This is not something we can prevent from happening in the future - but we need to mitigate the impact this could have - and it has been agreed with the Red Rock consultant (Andy Ross) that the best strategy is to institute a "black out" on all PHRIS web service calls from midnight to 5 AM (this includes a buffer of about a couple of hours either side of the activity).

Looking at the IdB 3.0.7 timing documentation I can see that this idea is supported in this version of the product, but I would appreciate confirmation of the correct use of this setting in my current connector configuration.

The JOB connector timing is presently configured as follows:

        <getAllEntities>
          <timing name="RecurringTimespanStandardTime">
            <timespan value="01:00:00" />
          </timing>
        </getAllEntities>
        <polling>
          <timing name="RecurringTimespanStandardTime">
            <timespan value="00:01:00" />
          </timing>
        </polling>

Am I correct in understanding that I should change the above to the following to achieve the desired "black out"?

        <getAllEntities>
			<timing name="DailyExclusion" start="00:00:01" end="05:00:00" UseLocal="True">
				<timing name="RecurringTimespanStandardTime">
					<timespan value="01:00:00" />
				</timing>
			</timing>
        </getAllEntities>
        <polling>
			<timing name="DailyExclusion" start="00:00:01" end="05:00:00" UseLocal="True">
				<timing name="RecurringTimespanStandardTime">
					<timespan value="00:01:00" />
				</timing>
			</timing>
        </polling>

Appreciate your help with a simple yes/no (plus fix) answer - I am about to start testing the above idea in the lab but thought it would be best to seek confirmation that this will work as I expect.

Add support for SCIM 2.0 to support outbound provisioning from AAD, PingFederate

Request

https://unifysolutions.jira.com/wiki/display/IDB50/LDAP+Configuration

In Identity Broker 5.X, if services on other servers need to contact Identity Broker you have to supply the servers IP address. I have the following questions:

a) The UI does not allow me to enter in another servers IP address, if I do this I get a message stating the IP is not valid in the current context. This is good. What happens however if the servers IP address was to be changed. Will Identity Broker pick this up and compensate when it's next restarted, will it fail to start or will something else happen?

b) Is there any reason this field can't take in the fully qualified domain name of the server? The FIM Administrators aren't likely to be network administrators, so ideally they could configure services with a higher level of granularity than an IP address (which they don't manage). 127.0.0.1 is ok for localhost as it's universal, anything else might cause issues based on the behaviour in question A.

c) As an extension of part b, could the field be removed outright? If traffic is to be restricted to localhost firewall rules could be used on the assigned port.

Task

• Update documentation to let users know that IdB can be bound to any IP.
• Make the any IP easier to configure on the UI
• Consider offering ability to select the IP (or preferably the network adapter) (keep in mind this should come from the server and not studio)