We appreciate you taking the time to vote and add your suggestions to make our products awesome! Your request will be submitted to the community for review and inclusion into the backlog.

We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.

For more information around feature requests in the Cireson Community click here.

Security Granularity for Request Offerings Within a Service Offering

We've been defining Service Offerings by who is providing the service (e.g. IT, HR, etc) meaning all Request Offerings for things IT would do, are in the same Service Offering. In the built-in portal using Security Roles, and Catalog Groups we can scope Request offerings to specific Security Roles, and depending on who you are, you see special Request Offerings for your role, in addition to all the services available from IT for everyone. In the Cireson portal I was informed by a technician that users can see any Request Offering within a Service Offering they have access to; this means we'll need to instead define our Service Offerings by who is making the request, as opposed to who is providing the service. It would be nice if the Cireson portal handled this in the same way as the default portal, and Catalogue Groups could be used to scope access to both Service Offerings, and Request Offerings.
67 votes

Accepted · Last Updated

We are still looking at this. It was a decision on our side early in the products life to support it this way, and many customers rely on this structure. We understand this would help others though, and are looking for ways to switch between the two methods.

Comments

  • Geoff_RossGeoff_Ross Cireson Consultant Super IT Monkey ✭✭✭✭✭
    Hi Keith,
    Not sure where that information came from but that's not quite correct. What you are doing sounds great and you can scope out certain ROs to different people within one SO. In order to see an RO, it must be in a SO, a user must have access to the RO and it's SO via a catalog group and both must be published.
    Hope that helps,
    Geoff
  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    I think its still just based on service offering level permissions (IR28086, IR28389, KB1257) unless it was recently changed. 

    @chris_ross are you able to confirm or advise if this one is still on the backlog to change permissions here?
  • Keith_ChristoffersonKeith_Christofferson Partner Adept IT Monkey ✭✭
    Hi Keith,
    Not sure where that information came from but that's not quite correct. What you are doing sounds great and you can scope out certain ROs to different people within one SO. In order to see an RO, it must be in a SO, a user must have access to the RO and it's SO via a catalog group and both must be published.
    Hope that helps,
    Geoff

    So, that is not the behavior I'm seeing. I've confirmed, that in the Silverlight SCSM portal, security functions as I expect (as you describe) but in the Cireson portal, it does not. When I opened a ticket with support to figure it out, I was told that security scoping is not granular within a SO, and that I should split my SO's based on who I want to see the RO's. As with Joe, I'm super curious, if you know how to do this, please let me know, I'd love to not have to change all my existing SO's.
  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    Hi Keith,
    Not sure where that information came from but that's not quite correct. What you are doing sounds great and you can scope out certain ROs to different people within one SO. In order to see an RO, it must be in a SO, a user must have access to the RO and it's SO via a catalog group and both must be published.
    Hope that helps,
    Geoff
    What Geoff is describing would be the permissions in the default MSFT OOB portal. The permissions structure there can be tiered for both SO and RO. Within the Cireson portal all permissions are based on SO permissions.

    That being said you can have multiple SO with the same name and different permissions if you desire to scope sections of the SO down to a smaller number of folks.
  • Keith_ChristoffersonKeith_Christofferson Partner Adept IT Monkey ✭✭
    edited June 2016
    Hi Keith,
    Not sure where that information came from but that's not quite correct. What you are doing sounds great and you can scope out certain ROs to different people within one SO. In order to see an RO, it must be in a SO, a user must have access to the RO and it's SO via a catalog group and both must be published.
    Hope that helps,
    Geoff
    What Geoff is describing would be the permissions in the default MSFT OOB portal. The permissions structure there can be tiered for both SO and RO. Within the Cireson portal all permissions are based on SO permissions.

    That being said you can have multiple SO with the same name and different permissions if you desire to scope sections of the SO down to a smaller number of folks.

    Right, I just have all the security already setup, and if a client would be going from the OOB portal, to Cireson, not having to rework security at all would be nice.
  • Geoff_RossGeoff_Ross Cireson Consultant Super IT Monkey ✭✭✭✭✭
    Hi Keith,
    I have been rebuked by my colleagues. I stand corrected, I'll up-vote as this would be nice seeing as this is how it thought it worked. 
    Apologies for the miss information.
    Geoff
  • Keith_ChristoffersonKeith_Christofferson Partner Adept IT Monkey ✭✭
    Hi Keith,
    I have been rebuked by my colleagues. I stand corrected, I'll up-vote as this would be nice seeing as this is how it thought it worked. 
    Apologies for the miss information.
    Geoff

    No problem! I'm pretty sure it worked in my environment in V2 (at least for users in the same domain as the SCSM server), I just assumed it'd work in V5 as well. I'll probably just end up reworking SO's for now as a work-around and recommend the same to and clients.
  • Chris_JordanChris_Jordan Customer Adept IT Monkey ✭✭
    edited July 2016
    I was genuinely surprised and disappointed when hearing this wasn't included in the initial scope.

    My manager has asked me for this as I told him scoping was there (wasn't aware of this limitation at the time of course). So not sure how I am going to do this for him now.

  • Steve_WrightSteve_Wright Cireson Support Advanced IT Monkey ✭✭✭
    Hi Chris,
    I updated your service support ticket - please let me know if you have any additional questions/concerns.

    Thanks,
    Steve
  • Candice_YeudallCandice_Yeudall Customer Advanced IT Monkey ✭✭✭
    @Chris_Jordan you are not the only one who is having issues with this, I need to be able to scope not just SR but access to IRs as well and the only solution seems to be custom forms which will not work.  :/
  • Jonathan_BolesJonathan_Boles Customer Ninja IT Monkey ✭✭✭✭
    I'm hoping we see this fix/feature on a release soon! We've had to create a number of duplicate SOs for this limitation and it makes administration less than efficient when you have to have 12+ SOs with the same name. 
  • Sam_PackerSam_Packer Customer IT Monkey ✭
    Is this still an issue? I was told today that my end users could see all of our internal offerings, and indeed they can. The only way I got them to not see them was to make them "draft", and now no one can see them. We are on version 7.2.2012.1. Any help appreciated, thanks.
  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    Is this still an issue? I was told today that my end users could see all of our internal offerings, and indeed they can. The only way I got them to not see them was to make them "draft", and now no one can see them. We are on version 7.2.2012.1. Any help appreciated, thanks.
    Currently you still cannot at the RO level, only SO level. But possible with the workaround @seth_coussens
    metions.

    So depending how you are currently catalog scoping. You would want to remove your "internal offerings" from any of the the end service offerings you have scoped to your end user role. Or create new catalog groups for your end users and scope to your role.
  • Ryan_EkhoffRyan_Ekhoff Customer IT Monkey ✭

    Do we have any ETA on this being fixed?

    We are currently using the method described by using multiple similarly named Service Offerings, but have come across a few issues with this method:

    • URL's are unique for the same RO that is in different SO (because the URL is based on a combination of both RO and SO GUID). This makes providing direct links to RO a contextual nightmare for our Help Desk.

    • It is difficult to maintain, as in our environment the desire is to have an SO with a name that does not also include the scope, as this would look sloppy. But for our Help Desk, this means they are unsure which of multiple similarly named SOs contains the correct RO, and have to open the RO to check the SO’s description, which is where we express the scope.

    Now we could re-work the Service Catalog to show the SO’s description, but that isn’t nearly as clean as just having the Catalog Group’s scope of ROs taken into consideration.

    An ETA would be really appriciated as it would save us a great deal of time and effort.

  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭

    Do we have any ETA on this being fixed?

    We are currently using the method described by using multiple similarly named Service Offerings, but have come across a few issues with this method:

    • URL's are unique for the same RO that is in different SO (because the URL is based on a combination of both RO and SO GUID). This makes providing direct links to RO a contextual nightmare for our Help Desk.

    • It is difficult to maintain, as in our environment the desire is to have an SO with a name that does not also include the scope, as this would look sloppy. But for our Help Desk, this means they are unsure which of multiple similarly named SOs contains the correct RO, and have to open the RO to check the SO’s description, which is where we express the scope.

    Now we could re-work the Service Catalog to show the SO’s description, but that isn’t nearly as clean as just having the Catalog Group’s scope of ROs taken into consideration.

    An ETA would be really appriciated as it would save us a great deal of time and effort.

    Currently, this is not on the backlog for 2017, but based on your comments here I will bring this up with the team again and see what they level of effort on a change here would be and will update this discussion at that time.
  • Ryan_EkhoffRyan_Ekhoff Customer IT Monkey ✭

    Thank you Seth, I really appreciate it.

    If it helps for context, here are some examples of the struggles. In our environments, the Request Offerings available can include scope based on Security Groups that include:

    • Physical location of the End User (different workflow based on being on-or-off campus)
    • Company/Org of the End User (different workflow for some Orgs)
    • Existing inclusion in an AD Group (Maybe you get new ROs available within some SO once you've been granted some AD controlled access)
    • Citizenship of Employee (sometimes export control laws can include make offering an RO dependent on where the End User is a citizen).

    The trick here is that some ROs need to factor in multiple of these categories at one time. This is a handful, but can be done with AD Groups and Catalog Groups. Without being able to scope down to the RO, you can imagine how out of hand this could get.

    Right now we've limited scoping to a bare minimum to avoid the issue, but this has resulted in creating RunBooks that check the Affected User's membership, and sometimes outright cancel the SR that's generated because the End User shouldn't have submitted it. Not a great end-user experience, and we'd love to have them just not see the stuff they shouldn't.

  • Ryan_EkhoffRyan_Ekhoff Customer IT Monkey ✭


    Do we have any ETA on this being fixed?

    We are currently using the method described by using multiple similarly named Service Offerings, but have come across a few issues with this method:

    • URL's are unique for the same RO that is in different SO (because the URL is based on a combination of both RO and SO GUID). This makes providing direct links to RO a contextual nightmare for our Help Desk.

    • It is difficult to maintain, as in our environment the desire is to have an SO with a name that does not also include the scope, as this would look sloppy. But for our Help Desk, this means they are unsure which of multiple similarly named SOs contains the correct RO, and have to open the RO to check the SO’s description, which is where we express the scope.

    Now we could re-work the Service Catalog to show the SO’s description, but that isn’t nearly as clean as just having the Catalog Group’s scope of ROs taken into consideration.

    An ETA would be really appriciated as it would save us a great deal of time and effort.

    Currently, this is not on the backlog for 2017, but based on your comments here I will bring this up with the team again and see what they level of effort on a change here would be and will update this discussion at that time.

    Any update on this? I am being ask to again add additional security scoping which is going to result in another round of headaches. As these could all be resolved if RO's where able to respect the existing security scope. This is becoming more and more of an issue for us.

    If opening a feature request on the support site would apply additional pressure to this, I will gladly do so. This is a major need within our organization.

  • seth_coussensseth_coussens Product Owner Ninja IT Monkey ✭✭✭✭
    There is a pretty high level of effort here, as it would require changes both within the CacheBuilder service and the Portal front end as well. Additionally, as this has to do with additional scoping the current method we use for SO was designed to keep performance high. 

    It's possible we will be revisiting some scoping performance changes in the near future, in which case this would be a part of that process. Outside of when that time comes, this request is not currently one of the top requests and so hasn't been picked up on it's own for implementation at this point.
  • Dieter_SaerensDieter_Saerens Partner IT Monkey ✭
    Is there any update about this matter?

  • Sean_TerrySean_Terry Customer Advanced IT Monkey ✭✭✭

    Is there any update on this? I was hoping to be able to restrict individual RO within a SO rather than creating lots of SOs. I was hoping this might give us some alternative options.

  • Gabriel_LencesGabriel_Lences Customer IT Monkey ✭

    This feature is far overdue, we would also love the ability to scope individual RO's instead of SO's in the portal!😊

    Hopefully this gets more and more votes.

  • Peter_MiklianPeter_Miklian Customer Advanced IT Monkey ✭✭✭
    edited 2:23PM

    Please, implement RO-level scoping. How can global companies offer same ROs with country-specific fields to their offices without this?

Sign In or Register to comment.