Page History

...

Groups and Roles in CO Context

Comments included:

Wiki MarkupDefinitions:

• A

...

• group

...

• is

...

• a

...

• collection

...

• of

...

• things.
• Roles – a set of duties that go with a position

StevenC: In a permission system, groups are one of the things that can get mapped to roles

A position (job title) can also get mapped to a role

Benn: the COmanage development effort does not currently include the objective of doing something with roles. We need requirements before we deal with roles.
TomB: Grouper incorporates the NIST RBAC model   Roles -- a set of duties that go with a position StevenC: In a permission system, groups are one of the things that can get mapped to roles A position (job title) can also get mapped to a role Benn: the COmanage development effort does not currently include the objective of doing something with roles. We need requirements before we deal with roles. TomB: Grouper incorporates the NIST RBAC model   [http://csrc.nist.gov/groups/SNS/rbac/

] RBAC includes notions of role hierarchy and inheritance

 inheritance
 \[AI\] (Keith) will make sure that the COmanage glossary covers roles and groups accurately.

https://spaces.at.internet2.edu/display/COmanage/Glossary

Status Update (Benn)

• Benn has added new items to COmanage JIRA https://bugs.internet2.edu/jira/browse/CO
• A lot of the JIRA items resulted from the recent conversations with LIGO
• Code is in SVN -- there is an anonymous SVN and an authenticated access SVN
• The anonymous SVN may lag behind the authenticated SVN
• The code corresponds to the demo running on Benn’s laptop
• Will move the COmanage demo to the Internet2 servers soon
• Benn is currently working on COmanage Gears (profile management)  
• Focus is on getting institutional identity and correlating that with the CO identity.

Q: Keith: Does COmanage Gears currently rely on some implementation of registry and/or Grouper?

...

Question: Is what VOs need in the social identity area simpler or different from what brick and mortar institutions need?

Jim: it depends. At Penn State, we are bricks and mortar but spread over 24 location but we have a strong central identity, so can organize Penn State VOs without Shib. But at other institutions, it's possible that they need Shib to make the institution more amenable to cross-unit collaborations

StevenC stated that there are three categories of use cases driving the social identity discussion:

...

Push Vs Pull Issue Raised on International Collab Call of 3-March-2011

• There  was discussion on the International Collab call of different collab management platforms
• Leif said Comaange is a push platform, whereas other models are pulling info
• This is set on the background of the Blakely article and idea that the future is pull, http://mms.businesswire.com/bwapps/mediaserver/ViewMedia?mgid=237020&vid=1
• There may be some perception of traditional Enterprise IdM where there is a central repository of info that gets pushed out to other systems that the central enterprise can thereby control.
• This perception is connected to central planning (push) and free market (pull)
• There are not currently apps that support the pull model, so it's hard to imagine it working in the near future
• An alternative for IdM folks is to offer an open service, but not sure how that relates to the VO scenarios
• Leif was talking about applications that can dynamically generate a query during processing. A kind of late binding, not something that happens at logon time. No applications do that today.

What we do see now in attribute aggregation is this scenario (Steven has a working demo for GENI that does this):

• I have a campus ID and I am a member of VO1
• VO1 has a portal, that serves as a front end for a device I can use.
• I login to the portal, using my campus ID,
• The portal is configured to query VO1
• VO1 provides info about my permissions.
• The portal agregrates what the campus provided and what VO1 provided
• That can be called reputation building.
• Steven noted that in case of GENI work, we might spit out x509 certificates into GENI space from COmanage, so there will be a single root for the commands coming into the apps from COmanage.

But is having COmanage as a broker going to simplify the trust process for the application?

...