Hi,

I guess You can create an ig application with a custom form and a fulfiller that creates an guest account with info from the form. Then collect the guest account as an identity in ig to be able to assign permissions and stuff. Maybe add the requester as custodian or someting.

I have done this to create new accounts for existing identities but not with a custom application form.

Another way may be to build a workflow, not sure about this thou.

Rehards,

Magnus

Hi,

As Magnus has already written, it would be possible to provide such an interface via custom forms. To provide a custom form, however, you need an requestable application/authorization, just as Magnus wrote.

Custom workflows allow a certain flexibility here, but you also have to look at how you can call up the custom workflow cleanly. Within the workflows, you also have the option of making REST calls with various authentication options. I can't say right now whether you can "easily" address the Azure API with this.

In my experience, the IG is not able to record master data cleanly, or generally just provide a form for which a workflow is then stored. As far as I know, a form must always be linked to a permission or application.

BR

Tobias

Thank you both for your replies.

If the form needs to be linked to an application, how will IG handle the fact that I as the requester already made an request for this application? Will I be allowed to make another request for this application to be able to create another guest user?

Regards,

Andreas

I can only tell you about “permissions”, not about “applications”. I haven't really had much to do with the latter, as I've never had a use case where I needed “applications” as such, or where they would have brought me added value. But I think the behavior is similar here (not 100% sure)

We had already considered making such a custom form available via a “fake” permission. However, the problem is exactly what you have described, if the authorization is successfully requested once, then the authorization would also be assigned and therefore you could not order it again. We were considering whether to store an approval workflow that directly rejects the order. This would allow the authorization to be ordered again and again, but the order history would always show a rejected workflow. Unfortunately, I have no real practical experience with this use case, as we have decided not to go down this route. (Background: We usually also use IDM with our customers and have made the forms available there)

PS: If I remember correctly, our last consideration was the following:
Custom Application -> Fake Permission (Name e.g “Create User”) -> Permission triggers custom request forms -> request triggers custom workflow -> in the workflow you do all the stuff you want to do (calucations, REST-Calls, etc) -> Approval Workflow will be denied so you can request the 'permission' again. 

However, we never implemented this because we simply didn't find it customer-friendly.

BR

Tobias

Whether it's a matter of permission or application is not the issue here. The real question is whether it can be done, and even if it can, how user-friendly it would be?

I'm not sure if it associate the application to the identity through the request or when the collector links the account to the identity.

If it's through the collector then it maybe ok because You would not link the guest account to the requesters identity so the requester should be able to request more than one guest account.

I don't know if it works this way but maybe Tobias or someone else does?

Anyways it should be ez to setup and try.

I've considered this a bit in the past.  It's definitely not something IG is designed to do. 
I prefer the approach to let the fulfillment system handle the provisioning of the account, I wouldn't recommend trying to do fulfillment in the workflow itself.  You'd want to leverage the capability of fulfillment like reporting, retries, etc.  There is a lot it does for you, and handling all that in a workflow makes me shudder.

You might even be able to use the out of box workflows, might not need a custom one here.

The kicker is how to make the request against an app (or a permission) and not prevent someone from making a second request.  Keep in mind you can request on behalf of others, so that might be a way for a manager to request several accounts for direct reports - however, you'd need an identity in place for those reports first.

Another approach might be to use a custom workflow, but change the request midstream to swap out from a fake app/permission to a different one that you actually intend to fulfill.  In this case you might hide a bunch of perms from the request interface, provide the users one fake one, then during the request select the appropriate permission for them.   Fulfillment would occur as normal, and as long as each user only requests one and only one of each thing, you'd be good?

I'd love it if we could make arbitrary workflows run that weren't tied to perms, however there is definitely a trade off there.

--Jim

In this scenario we have both the identity source and AD collector using the same AD... so if the guest account where to be created, wouldn't it be creating it's own identity object in IG and link the newly created guest AD account to that identity?

Yup - your manager or requesting user wouldn't be able to select a different identity or direct report to create the account for.   In this case its similar to a request for a separate service account then.

I total agree with " It's definitely not something IG is designed to do."

Yes, your right. Using a fulfillment is probably the better way for the provisioning part.

"I'd love it if we could make arbitrary workflows run that weren't tied to perms, however there is definitely a trade off there." -> Totaly agree! This has always been an issue for us in the past, as we didn't want the role order to be placed in the IG, but the rest of the forms to be called up in the IDM. In order to offer a uniform interface here, but perhaps this will be possible at some point.