I have configured the following adapter which references a placeholder PERSON connector, and I am trying to get back an "Orgs" collection using a Relation.Group.dn transformation. The following is my adapter configuration:

        <!-- 000 Person -->
        <AdapterConfiguration BaseConnectorId="{A672CB12-2CA2-498b-8992-EAB883A1FC44}"
              AdapterId="{8291D830-AAA8-4e69-B4E7-AB1C4ABA53E7}"
              AdapterName="Person Adapter"
              class="person" >
          <dn>
            <dnComponent name="Field" key="AccountName" attributeType="UID" />
            <dnComponent name="Constant" value="People" attributeType="OU" />
          </dn>
          <adapterEntityTransformationFactory name="ChainList">
            <adapter name="Relation.Group.dn"
               InputKey ="AccountName"
               RelationshipConnectorId ="{429AE766-0A1F-404a-ACC1-B4804C859146}"
               RelationKey ="UserIDName"
               RelationReference ="subKey"
               GroupTarget="Orgs">
              <dn>
                <dnComponent name="Field" key="Code" attributeType="UID" />
                <dnComponent name="Constant" value="Orgs" attributeType="OU" />
              </dn>
            </adapter>
          </adapterEntityTransformationFactory>
          <image>removed</image>
        </AdapterConfiguration>

The problem I have is that this will return all (distinct) subKey objects associated with the UserIDName derived from an existing claims connector, where I only want to return those where another claims attribute ApplicationName="ESS". Is this possible, and if so how?

Update the agent UI so that the content type setting automatically switches when that agent type setting is changed:

When somebody has a chance, can you please create a 64-bit installer for this?

No rush as x86 works fine, just means I have to copy files which is a bit of a pain

Cheers

I have a requirement to send a password in clear text within the HTTP header (only protection is SSL) when calling the SAP ODATA API. This cannot be in encoded form, so I cannot use the standard approach used say when calling the Exchange API to provision a mailbox. Is there a way that an encoded password can be accessed and decoded from within the Identity Broker configuration itself (e.g. via a $variable), so that it is not exposed to anyone viewing the IdB configuration?

As an alternative to the Exchange style file-based encoding mechanism I am saving the Base64 encoded password to a text file for now, but this is not exactly secure. If the answer to the above is no, and there are any alternatives that you are aware of please advise.

CSO have deployed an Identity Broker for SAS2IDM, which is a custom application (apparently written in-house by CSO?) which does nothing more than consolidate data from 43 school "SAS2000" instances of the same remote SQL database table into a consolidated single database (not sure but I think to separate tables within the same db) ... and at the same time constructing a unique key (school ID concatenated to student ID). This is achieved using a monolithic database view (suspect this is a SQL union).

Given that this tool was built (it seems) prior to UNIFY's engagement (some time after March 2011) to build the Identity Broker for SAS2IDM (CA November 2011 - although Shane Lim may have built an earlier version which wasn't used), there appears to be no discussion about how Identity Broker might be used to access each SAS2000 database using 43 separate instances of the same connector schema, and combine them into a single adapter, thereby making the SAS2IDM application redundant. This would be a good thing as it would dramatically simplify the architecture.

The question is this ...

Can such an adapter be built now using the latest 3.0.7 version of the Identity Broker software, using an adapter configuration something like the following:

compositeAdapterConfiguration>
<AdapterEngineCOnfigurations>
<Adapter Configuration BaseConnectorID="1" class="person />
<Adapter Configuration BaseConnectorID="2" class="person />
<Adapter Configuration BaseConnectorID="3" class="person />
...

or would a new transformation(s) need to be developed to support this?

Given that I can think of 2 sites where this requirement would have been considered too (News Ltd before they consolidated on a single HR instance, and an ACT education site somewhere), I expect this concept is not new.

To explain the architectural reason for consolidating 43 connectors into a single adapter like this is so that we have a single FIM MA with a single CS/MV/Portal object, currently managed by 10+10+10 FIM policy objects. If we tried to suggest 43 management agents here, that totally wouldn't fly (43x30=1290 FIM policy objects and a maintenance nightmare).

I am trying to configure IB to log different severity to different logs.

I have configured

<?xml version="1.0" encoding="utf-8" ?>
<LogWriter name="LogWriterFilterDecorator">
<logFilter name="Severity" severity="Error" />
<LogWriter name="CustomEventLog" customEventLog="IdentityBroker" />
<logFilter name="Severity" severity="All" />
<LogWriter name="CSV" prefix="IdentityBroker" directory="L:\Logs\Identity Broker" days="7" />
</LogWriter>

Is this config correct ?

What else do I need to do to see an Windows Event Log of "IdentiyBroker" ?

Do I need to and how can you explain how to configure .Net config to EventLogPermissionAccess.Write ?

TIA

I cannot see IB Service or the SAS2IDM connector in Control Panel Programs unless I log in as user who installed them.
Richard Courtney installed IB and if I log in as him I see ALL IB components in CP programs. I have tried two other domain and local admins but only see the IB FIM component (and the EB components)

At this moment I must therefore login as the "installer" if I want to un-install.

Debug mode introduced for v3.0.6.1 logs each line from Chris21 a repeated number of times to the Identity Broker log, meaning the log grows larger than it needs to when attempting to debug a specific connector.

The following error appears for pluggable views when using IIS. The issue may be to do with the permission set required by the IIS user, although I am logged on as the local and domain Administrator account and using Windows authentication:

Additionally connector images are not coming through.

Microsoft has announced a number of features are to be deprecated in "the next FIM version" as described at http://technet.microsoft.com/en-us/library/jj879229(v=ws.10).aspx. In particular, the following need to be updated:

• IDB-312 - ECMA2 support
• Updating the default run profiles for the xMA such that they do not contain single step run profiles (ie. "full import and full synchronization")