Five things about the FIM Portal

I’m having a big FIM week this week – in fact it’s more like a FIM Fortnight! I’ve delivered a three day training, demonstrated the product to a client, and I’m presenting FIM at a half-day seminar next week. (See here if you happen to be in Vaud, CH and you’d like to come.)

So while I’m doing and thinking all things FIM I’ve decided to start a little “Five things about” blog series on different aspects of the new platform. To start – some generalities about the FIM Portal (aka All The New Sharepointy Stuff).

1. It’s a framework

I have always told people that ILM is a framework, instead of a complete OOB solution. And then, before their eyes completely glazed over, I have attempted to impress on them that this is a Good Thing! IdM is an inherently complex problem, with every organisation having their own perculiarities, and I firmly believe that workable IdM must be grown into the environment, preferably in a standards-based, manageable way.

ILM always ticked these boxes for me and now, with FIM, Microsoft have extended the notion to the Portal. Essentially we have a new framework for defining the schema, workflows, permissions and data-entry points. RC1 comes with a schema and a starter collection of policies, sets and workflows – but you are free to view these as suggestions which you may change or build upon.

2. Sequential processing

Those of us who work with ILM have come to think in its “steady-state” way, where all we care about is the state of the data right now. The Portal operates in a sequential way, and I had to get used to it.

I was following Jorge’s method to get around the lack of an “IsPresent” qualifier when I realised I didn’t actually need it. We had made a very simple form to request a user account through the web services and I wanted to use a workflow to generate system-type attributes such as Account Name, Display Name and Employee ID. My immediate thought was to make a set of “Account Name not present” but that’s an ILM way of thinking – ie just look at the data now.

The FIM Portal way is to think about where the data came from. In this case it was the account I’d created for the web service. I modified the MPR that gave rights to the service account, and now it also runs the Workflow that generates the attributes. Obvious in retrospect, but it did make me realise I had to adopt a more sequential way of thinking for the Portal.

3. The WS-* thing really is a big deal

I’ve heard a lot about the web services interface to the Portal but, not being a developer, I’d filed it under “find out more later”. But now I’ve had the chance to work with a developer colleague for a couple of days and have seen how excited he is about the possibilities.

With RC1 he did have some tedious mucking about with library versions first (something about an x64/x32 conflict – don’t ask me more), but once that was sorted he showed me how simple the code is.

I started to think about how important it is that we’re not being tied to the Portal interface to use it. Many organisations will already have existing portals where people are accustomed to find data and make requests – this way those interfaces can be modified to access the Portal at the back-end, and users don’t need to worry about learning something different.

4. It is distinct from the sync service, and that is fine

I have been told that I should consider the metaverse and the data in the Portal as the same thing – but they’re not, and actually I don’t see that as a problem. The Sync Service is a distinct unit and, for it, the FIM Portal is just another connected data source. I am very comfortable with the idea of preparing my data in the Portal and then, when it is ready, sync’ing it through the Sync Service.

This has also led me to the decision that I won’t be using the Portal-based Sync Rules, at least for the first release. I do have concerns about performance and troubleshooting which have not been allayed but what I see in RC1 but, more fundamentally than that, I want to keep the configuration of the Sync Service within the Sync Service.

Partly it is to do with seperating the part of the product that is mature and stable, from the part of the product that is completely new. Many people I talk to are interested, but concerned about adopting a “version one” product. I am hoping that the product being only “half new” will seem like an acceptable risk. I need to be able to guarantee that the half which isn’t new will perform without problems.

5. All Resources are treated in similar ways

Resources are just objects that exist within the Portal. These are users and groups, but also the things that make up the functionality of the Portal – like Workflow Activities, and Requests, and MPRs.

Because they’re all just Resources, the methods for interacting with them are repeatable. So when I wanted to give the Administrator account access to add a new workflow activity, I followed exactly the same process as giving a user the permission to create a group. If I want to change a form, or add a new attribute, it will be the same process for any resource type. This reapplication of methods should certainly make the Portal easier to learn!