Topic
  • 10 replies
  • Latest Post - ‏2014-06-21T00:41:48Z by Mani_kandan90
Jacob99
Jacob99
2 Posts

Pinned topic ITIM: Restrict users from applying for more than 1 account per service

‏2013-10-14T18:34:16Z |

Hi all,

I am new to ITIM.

Currently the users are able to request for accounts of the same service even though they already have an account.

I would like to check if it's possible to restrict the users from making such requests  ie. 1 user is only allowed to have 1 account per service by configuring ITIM?

 

Regards

Updated on 2013-10-14T18:34:39Z at 2013-10-14T18:34:39Z by Jacob99
  • yn2000
    yn2000
    1086 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-10-14T21:27:28Z  

    Prov. Pol. entitlement usually means that the user is entitled (allowed) to have an account and that is it. By default there is no restriction on how many accounts the user can have. In fact, it is a feature of ITIM to allow user to have more than one account in the target, because some other products need a great deal of customization to allow a user has more than one account. Having said, I think if you explain the situation in more detail, such as why you need only one account in the target? what happen if the user is created from the target? where do you want to block it? etc.?, the forum might be able to answer with a more detailed description.

    For example: You can modify the operational workflow, such as if the account is created; you set a flag in the person entity; then the flag will trigger a role; then the role will trigger ITIM groups; then the ITIM groups trigger ACI; and the ACI will block the user to add or request the account. There are many variant or short cut on this idea.

    Another example: You can also configure TIM to allow the user to 'request', but not to 'have', meaning the second request will failed, if the first account is already existed. For this, you can create a Prov. Pol. where the eruid (Login ID) equal to uid and configure the ACI where the user is not allowed to change the eruid (Login ID) value. So, basically the Login ID is stuck with uid value. Therefore, the second request will fail if the user is requesting the account twice. You can have many variant on this idea too.

    Another example: Give it to human to decide, meaning that you create an approval workflow on any account request processing. If the human said OK, then it is OK. If the human said No, then it is No. You can also have a variant on this idea, such as instead of human, you build a logic to check the existence of an old account; and notify the requestee, etc. etc.

    Rgds. YN.

  • Jacob99
    Jacob99
    2 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-10-15T04:06:22Z  
    • yn2000
    • ‏2013-10-14T21:27:28Z

    Prov. Pol. entitlement usually means that the user is entitled (allowed) to have an account and that is it. By default there is no restriction on how many accounts the user can have. In fact, it is a feature of ITIM to allow user to have more than one account in the target, because some other products need a great deal of customization to allow a user has more than one account. Having said, I think if you explain the situation in more detail, such as why you need only one account in the target? what happen if the user is created from the target? where do you want to block it? etc.?, the forum might be able to answer with a more detailed description.

    For example: You can modify the operational workflow, such as if the account is created; you set a flag in the person entity; then the flag will trigger a role; then the role will trigger ITIM groups; then the ITIM groups trigger ACI; and the ACI will block the user to add or request the account. There are many variant or short cut on this idea.

    Another example: You can also configure TIM to allow the user to 'request', but not to 'have', meaning the second request will failed, if the first account is already existed. For this, you can create a Prov. Pol. where the eruid (Login ID) equal to uid and configure the ACI where the user is not allowed to change the eruid (Login ID) value. So, basically the Login ID is stuck with uid value. Therefore, the second request will fail if the user is requesting the account twice. You can have many variant on this idea too.

    Another example: Give it to human to decide, meaning that you create an approval workflow on any account request processing. If the human said OK, then it is OK. If the human said No, then it is No. You can also have a variant on this idea, such as instead of human, you build a logic to check the existence of an old account; and notify the requestee, etc. etc.

    Rgds. YN.

    Hi yn2000,

    Thanks for your reply.

     

    Our ITIM has a few services such a AD, managed resources, and a customized adapter for an application. The requirement is that 1 user cannot have more than 1 account for each services.

    The users are automatically granted to certain accounts based on RBAC,  They will be allowed to request for accounts that they are not entitled through a requester.  The requester have rights to search for all the services in ITIM.

    I am thinking if it's possible to prompt a message to the requester informing him/her the user that he/she is trying to make a request for account already has the account for that service in the manage users page itself.

     

    Regards,

    Jacob99

  • franzw
    franzw
    347 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-10-15T06:37:30Z  
    • Jacob99
    • ‏2013-10-15T04:06:22Z

    Hi yn2000,

    Thanks for your reply.

     

    Our ITIM has a few services such a AD, managed resources, and a customized adapter for an application. The requirement is that 1 user cannot have more than 1 account for each services.

    The users are automatically granted to certain accounts based on RBAC,  They will be allowed to request for accounts that they are not entitled through a requester.  The requester have rights to search for all the services in ITIM.

    I am thinking if it's possible to prompt a message to the requester informing him/her the user that he/she is trying to make a request for account already has the account for that service in the manage users page itself.

     

    Regards,

    Jacob99

    There is something wrong in your picture - if you go RBAC then there is no need to have "request account" available to endusers - the "request vehicle" should be roles. When you request a role and account does not exist it will be created - and if you remove the role the account will be  removed (the latter might be a problem - but you can do some magic in the operational workflow that takes care of that).

    As I see it what is needed is a hybrid model so that you can handle exceptions to the generic rule - we discussed this here in this very forum some days ago how to do that. But IMHO there are no easy ways to have a fully controlled (and hopefully highly automated) system that also provides a consistent request model to the enduser - this is complex model that requires a lot of knowledge and experience (I think everybody that started out in the 2003 time frame and has done these kind of things knows what I am talking about).

    Let me give you some more theoretical things to think about. When you look at the different requests an enduser can perform - on which entity level is it performed ? And what is the consequence ?

    1. Account request - this is easy - the entity is obviously the account
    2. Access request - a pure access is account - but if the access is a role it is really a person entity change
    3. Account modification - again easy - the entity is  account
    4. My profile modification - also easy - person entity.

    The problem here is this mixture and the policy enforcement model - if you use "mark" - then you cannot restrict the enduser - you need to use approvals - if you use "correct" (my recommendation as this is IMHO the only way to automate) you need to make sure that your provisioning policies are fully handling what ever you offer the enduser - you cannot put approval on something that is "mandatory" unless you can remove the offending request in case of rejection. Account level requests will have to managed carefully mixing "allow" policies and "mandatory" entitllement....

    Also you need to very careful about what you do in your operations - you must never try to change attribute values of accounts in operations unless you can make sure that these are never included in provisioning policies - and this is mostly practical impossible.

    Basically it is the job of the system architect to ensure that this defined - hopefully before the implementation....

    Food for some thinking ?

    HTH

    Regards

    Franz Wolfhagen

  • yn2000
    yn2000
    1086 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-10-15T12:41:56Z  
    • Jacob99
    • ‏2013-10-15T04:06:22Z

    Hi yn2000,

    Thanks for your reply.

     

    Our ITIM has a few services such a AD, managed resources, and a customized adapter for an application. The requirement is that 1 user cannot have more than 1 account for each services.

    The users are automatically granted to certain accounts based on RBAC,  They will be allowed to request for accounts that they are not entitled through a requester.  The requester have rights to search for all the services in ITIM.

    I am thinking if it's possible to prompt a message to the requester informing him/her the user that he/she is trying to make a request for account already has the account for that service in the manage users page itself.

     

    Regards,

    Jacob99

    You see Jacob, sometimes I have to lie, just to make someone understand the concept first. For example: You said "…allowed to request for accounts that they are not entitled…" For me, that is a wrong concept. So, here is what my lying answer approach sound.

    ITIM is RBAC. Period. So, your design is based on the Role. Period. Users are getting what they are entitled. Period. Entitled means Allowed. After that, you told the customer, some of them, you create it automatically; some of them, the users have to request for it. Do you see the difference? The 'Request Based' design is inside of the 'Role Based' design. The users are NOT allowed to request the account if they are NOT entitled. After that, using the same Role design, you control with ACI on which account the user allowed to request.

    "…it's possible to prompt a message to the requester informing him/her the user that he/she is trying to make a request for account already has the account..."? Nope. Well, at least not in the level of interaction that you might have expected. You can block before the user making the request or you can block after the user making the request, but not during the user making the request.

    After a couple of years knowing that Santa is existed, you will figure it out your selves that Franz post makes more sense than mine. :-)

    Rgds. YN.

  • goonitsupport
    goonitsupport
    103 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-10-16T10:17:05Z  
    • yn2000
    • ‏2013-10-15T12:41:56Z

    You see Jacob, sometimes I have to lie, just to make someone understand the concept first. For example: You said "…allowed to request for accounts that they are not entitled…" For me, that is a wrong concept. So, here is what my lying answer approach sound.

    ITIM is RBAC. Period. So, your design is based on the Role. Period. Users are getting what they are entitled. Period. Entitled means Allowed. After that, you told the customer, some of them, you create it automatically; some of them, the users have to request for it. Do you see the difference? The 'Request Based' design is inside of the 'Role Based' design. The users are NOT allowed to request the account if they are NOT entitled. After that, using the same Role design, you control with ACI on which account the user allowed to request.

    "…it's possible to prompt a message to the requester informing him/her the user that he/she is trying to make a request for account already has the account..."? Nope. Well, at least not in the level of interaction that you might have expected. You can block before the user making the request or you can block after the user making the request, but not during the user making the request.

    After a couple of years knowing that Santa is existed, you will figure it out your selves that Franz post makes more sense than mine. :-)

    Rgds. YN.

    You can prevent multiple accounts being created (http://www-01.ibm.com/support/docview.wss?uid=swg21320014) but not being requested. There is no way to customise the ISIM console for this unfortunately but you could write your own.

    Let them request multiple but then send them an email to tell them it is not allowed is about the best you can do.

    Best regards,

  • VarunTIM
    VarunTIM
    21 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-11-17T08:10:27Z  

    Hi Jacob,

     

    The way i think to restrict more than one account is to add the ERUID attribute in the provisioning policy as a mandatory attribute and set the service enforcement to correct. So if the user already have an account on a particular service and if he tries to request another account it will through a non compliance on the request page as the ERUID that has been mapped in the provisioning policy is already existing on that service and the policy enforcement set as correct will not allow the user to change the ERUID, this way the user will not be able to request account on the service.

    HTH

    VarunTIM

  • franzw
    franzw
    347 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-11-17T15:01:52Z  
    • VarunTIM
    • ‏2013-11-17T08:10:27Z

    Hi Jacob,

     

    The way i think to restrict more than one account is to add the ERUID attribute in the provisioning policy as a mandatory attribute and set the service enforcement to correct. So if the user already have an account on a particular service and if he tries to request another account it will through a non compliance on the request page as the ERUID that has been mapped in the provisioning policy is already existing on that service and the policy enforcement set as correct will not allow the user to change the ERUID, this way the user will not be able to request account on the service.

    HTH

    VarunTIM

    Please do not follow this advice - this is a bad idea (not from the idea point of view - there it is actually pretty good). The reason is that this will only work if the service is set to "Mark" - and basically you should of architectural reasons place the functionality where it belongs.

    Userids are calculated in identity policies - so if you want this functionality you should place it there - e.g. you could a return a null eruid from the policy and check for that in the add workflows...

    You do something like this you may get into trouble with future functionality of ISIM - and having to recode this kind of things in the middle of putting in a new fixpack is not a situation I would like to be in :-)

    Regards

    Franz Wolfhagen

  • VarunTIM
    VarunTIM
    21 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-11-17T15:12:50Z  
    • franzw
    • ‏2013-11-17T15:01:52Z

    Please do not follow this advice - this is a bad idea (not from the idea point of view - there it is actually pretty good). The reason is that this will only work if the service is set to "Mark" - and basically you should of architectural reasons place the functionality where it belongs.

    Userids are calculated in identity policies - so if you want this functionality you should place it there - e.g. you could a return a null eruid from the policy and check for that in the add workflows...

    You do something like this you may get into trouble with future functionality of ISIM - and having to recode this kind of things in the middle of putting in a new fixpack is not a situation I would like to be in :-)

    Regards

    Franz Wolfhagen

    Hi Franz,

    Slight confusion on my part, if you set the service to mark it will allow you to enter any other user id and click ignore and if the user submits the form it will go and create an account on target. Hence I provided a condition to set the service to correct only, for this to work.

    My intention is not to contradict you however I would like to correct my understanding on the product.

    Thanks

    VarunTIM

  • franzw
    franzw
    347 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2013-11-17T15:29:38Z  
    • VarunTIM
    • ‏2013-11-17T15:12:50Z

    Hi Franz,

    Slight confusion on my part, if you set the service to mark it will allow you to enter any other user id and click ignore and if the user submits the form it will go and create an account on target. Hence I provided a condition to set the service to correct only, for this to work.

    My intention is not to contradict you however I would like to correct my understanding on the product.

    Thanks

    VarunTIM

    Your solution will work - until somebody comes in and needs 2 accounts on the same service. Your idea is right (but not your implementation ) - it is important to understand what the job of the provisioning policy is compared to identity and password policies. There are valid scenarios where you will need to be able to set eruid and erpassword in the provisioning policy - but as they violate the rule of doing things in the right place you must take great precautions if you do so.

    In general use identity policy for setting the eruid and password to set the password.

    The important thing to understand is the behavior of the complete system - not just what you CAN do somewhere.

    Regards

    Franz Wolfhagen

  • Mani_kandan90
    Mani_kandan90
    9 Posts

    Re: ITIM: Restrict users from applying for more than 1 account per service

    ‏2014-06-21T00:41:48Z  

    Hi jacob,

    Create identity policies to restrict

    Confugre entites for specific service and write code based on ur requirement. You can display error to user if he/she request again...

    Its easy to prevent users multiple account. Follow this.. it is working fine in my env..

     

    Regards,

    mani