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.

From SSICT-493, a certain condition was causing the chris21 service to return a PRG GTR line. This had not been seen before, but the details can be found on INTIDBCHRS:v7.7 Documentation, in CHRIS_BRE_SDK.pdf.

Essentially PRG is a progress message, why it's being returned is currently unknown, but it doesn't matter, it (and any other unknown line types) should be ignored.

From discussions on TATTS-7, allow for images to be saved and retrieved.

Please see attached demo code.

Either create a test application for POC, or add it straight to the product if you feel it will be quicker.

Thanks.

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)

It seems if a form has its EAI disabled, simply enable EAI will not allow connector to detect changes from it.
Steps I took to make connector to be able to detect changes:
1. Restart Chris21 service. (as a result, connector is not able to detect changes)
2. Restart IdB service. (as a result, connector is not able to detect changes)
3. Do a "Import all" and then modify some data in CHRIS21. (as a result, connector is able to detect changes)

From PRODUCT-7:

In order to aid diagnosis of failing processes, I think it would be a good idea for there to be a configurable option to provide detailed diagnosis information at every interface boundary within Identity Broker.

By that, I mean every Identity Broker process that has interfaces should be able to have a decorator inserted to provide details information about the methods and data provided at each step of a process. This would prevent the kinds of Product Support issues where: "I can't really tell what's going on so I suspect something is wrong with Identity Broker".

This could be achieved by implementing the interfaces of major boundaries, and logging debug information. IDB-84 (filter on log verbosity) will have to be looked at to avoid flooding the logs.