How to integrate an application for access administration with Microsoft Forefront Identity Manager 2010? RRS feed

  • Question

  • Greetings Techies,

    How to integrate an application for access administration with Microsoft Forefront Identity Manager 2010?

    Basically, we want to provide and manage access to users for a particular application (can be any application(s)) through Microsoft Forefront Identity Manager 2010.

    I would really appreciate suggestions of individuals for this. If you have any documents for the above said implementation please do share.

    Many thanks.

    Thursday, December 19, 2013 3:49 PM

All replies

  • there are a few questions:

    • how is the access to this application decided?
    • are there different type of users for this application?
    • by attribute in AD?
    • by groups in AD?
    • directly in the application?
    • if directly in the application
    • is there an interface to create the accounts?
    • are there workflows needed?
    • attestation about access needed?

    and so on.

    so it is possible but it depends on what you want and what the application needs

    Thursday, December 19, 2013 10:32 PM
  • Mr. Grippeling,

    Thank you for your reply. Please find answers o your questions.

    We have AD as an authentication server.

    We have decided to manage the access control through FIM. FIM will be the only point of contact where an user will be granted access to access the application. At the same time, we will be revoking the user's access from FIM only.

    Please suggest and help.


    Monday, December 23, 2013 10:46 AM
  • Before FIM included the BHOLD suite, I worked on two separate FIM projects in Australia whereby FIM was used for exactly this purpose:

    • the first was where custom myApplication resource types with designated owners were associated to users via a myUserResource resource type, together with an effectiveFrom and effectiveTo date:  FIM policy (MPRs/workflows/etc.) was created to manage/route approval for requests for access to these resources for a predetermined period (e.g. 3/6/9/12 months), and users granted access had a multi-value reference binding myApplications updated accordingly.  Every resource was associated with one or more dynamic groups, with group membership calculated based on the filter /Person[myApplications='<myApplicationGUID>'].  Temporal sets were used to ensure that once a myUserResource expired (today > effectiveTo date) the corresponding myApplication GUID was removed from the corresponding /Person.myApplications.  FIM groups and group memberships were then synchronised to AD, and AD ACLs were used to associate (AD-secured) application roles with corresponding group membership.
    • The second was an extension of the above idea, but where a custom client was used to manage Claim objects in FIM - which were then synchronised to a SQL database to drive an ADFS security model: Application-specific meta data (sites/roles/etc.) was synchronised to the FIM Service and used by Application administrators to associate users to application-specific roles.

    Both of the above are examples of how request-based access control can be implemented using FIM, together with re-attestation policy if need be (e.g. x days before an entitlement expires, alert a user to the need to re-attest for an extension to that access).  The second example, while not used in this case to drive group membership, demonstrates how application-specific roles can be associated with users using FIM - with one of the key benefits of doing this being the ability to delegate the administration of this access (e.g. "users can grant or deny access for other users to applications they own").

    The BHOLD approach is designed more with roles-based access in mind, and includes a BHOLD management agent designed to enable AD group membership to be easily provisioned based on application-role-user relationships defined in BHOLD.  You will have to read the BHOLD documentation (link above) to determine how closely this approach meets your requirements, or whether instead you need to use your own FIM extensions (like I did) instead.  Consider carefully the options available to you - with Microsoft's investment in the BHOLD platform it may be prudent to make every effort to leverage this technology, but if it is NOT a good match to your requirement, do not try to force the model to work for you :).

    Bob Bradley (FIMBob @ ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 11:51 AM
    Sunday, December 29, 2013 12:36 PM