Implementing Shibboleth - fine-grained access w/in an application

[Joe Blotner]

Sorry, Warren.  Different types of accounts.  Allow me to rephrase, using the word client instead of account:

Basically, what I'm understanding you to mean is that we create a mapping between people and clients, alongside a mapping of roles to permissions.  Then, when we assign the role to the user, he will only have that role on those clients to which he has been mapped.  Yes?


From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Curry, Warren
Sent: Tuesday, January 20, 2015 1:21 PM
To: Shib Users
Subject: RE: Implementing Shibboleth - fine-grained access w/in an application

In my world we do not have people share accounts.  People have accounts .  Services provide permissions to each person in an adequate manner.

How can you tell who did the change if multiple people use the same account?  It would seem unauditable for something like Budget ???? .

whc

From: users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> [mailto:users-bounces at shibboleth.net] On Behalf Of Joe Blotner
Sent: Tuesday, January 20, 2015 3:08 PM
To: 'Shib Users'
Subject: RE: Implementing Shibboleth - fine-grained access w/in an application

Thanks for the quick response, Warren.   Basically, what I'm understanding you to mean is that we create a mapping between people and accounts, alongside a mapping of roles to permissions.  Then, when we assign the role to the user, he will only have that role on those accounts to which he has been mapped.  Yes?

From: users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> [mailto:users-bounces at shibboleth.net] On Behalf Of Curry, Warren
Sent: Tuesday, January 20, 2015 11:39 AM
To: Shib Users
Subject: RE: Implementing Shibboleth - fine-grained access w/in an application

Assign individual account and do role based security.  The security may need to have extra granularity for specific department code that a person has that role for.  In turn you will need an attribute that you can encode this in.

This is very similar to many roles, and entitlement we use at our location.  We try to use master concept for this and not invent specific attribute for one application service.  That would not be a good idea.

You need  a general attribute you can encapsulate info within so that the SP can interpret and use it.

-whc

From: users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> [mailto:users-bounces at shibboleth.net] On Behalf Of Joe Blotner
Sent: Tuesday, January 20, 2015 2:12 PM
To: 'users at shibboleth.net'
Subject: Implementing Shibboleth - fine-grained access w/in an application

Hello,

We are a software development group who build custom webapps and apis used by both internal users and external clients and vendors.  We are doing a build vs buy analysis, and I am finding it challenging to see how we would leverage Shibboleth to solve one of our key usage needs.

Not only do we want to manage access to various applications, as well as features within applications, but also to business entities within our applications.  For example:
We have an account management application that includes a contract terms feature.  Within the contract terms, one can do many things, including change the client budget.  While we want everyone on the account management team to be able to see the budget data, there are only certain people we entrust to modify an account budget; we'll call those people "Budget Managers".  Further, each Budget Manager can only modify budgets for the subset of accounts for which they are responsible.

Has anyone used Shibboleth to solve a use case similar to this one?  If so, can you give me an overview of how it has been solved?

Thanks,
Joe


"More leads, less cost."

Joe Blotner | Senior Director, Product & Engineering
T 206.331.3536



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20150120/b27c5179/attachment.html