Entitlements
• The highest-order assignable object in
a security model
• Cataloging is more than just names
• Descriptions and meanings
• Owners, risk, sensitivity
Roles
• Multiple attempts to build role
models
• Regular, semi-homogenous orgs work
best
• Don’t try this with development shops
• No silver bullets have ever or will
ever exist
Membership Clause
• Governs eligibility
• Can be static
• Membership in business role
• Can be dynamic
• (orgUnitId in (102,103,53,142))
• Or combinations of both
Attributes & Entitlements
• Describes what needs to be set in
target systems
• Could be pointers to bundles of
entitlements
• More likely pointers + some
attributes that also need to be set
Fulfill this!
• Need to set attributes and assign
entitlements in the target systems
• How that is done is less and less
important
• User provisioning
• Help Desk ticket
• Email
• Directory sync
Access Certification
• Increasingly important in enterprise
• SP 800-53 AC-2
• Rise of Identity and Access Governance
• Separates operations from management
Telekinesis
• Want to effect the authorizations in a
remote system
• Provisioning local objects to effect
remote authorization state
Telekinesis
• Want to effect the authorizations in a
remote system
• Provisioning local objects to effect
remote authorization state
• But this is a hoax
Telekinesis
• Want to effect the authorizations in a
remote system
• Provisioning local objects to effect
remote authorization state
• But this is a hoax
• Provision remote objects too
Spray old data everywhere
• But now with less visibility
• RPs don’t know the quality of the data
Spray old data everywhere
• But now with less visibility
• RPs don’t know the quality of the data
• RPs don’t know the data’s “Sell By” date
Spray old data everywhere
• But now with less visibility
• RPs don’t know the quality of the data
• RPs don’t know the data’s “Sell By” date
• Information sources don’t always know
where the data went
But I wanna go on the ride...
• I’m tall enough
• But Mom doesn’t want me to ride the ride
But I wanna go on the ride...
• I’m tall enough
• But Mom doesn’t want me to ride the ride
• How does her “policy” get represented?
But I wanna go on the ride...
• I’m tall enough
• But Mom doesn’t want me to ride the ride
• How does her “policy” get represented?
• How is it acted upon?
Reference
• Gartner ITP / Burton Group Research
• The Emergent Architecture for Identity
Management - Bob Blakley
• Provisioning’s Role in the Next-Generation IdM
Architecture - Lori Rowland
• Characteristics of an Effective Identity
Management Governance Program - Kevin
Kampman
• Market Profile: Identity and Access Governance
2010 - Ian Glazer & Mark Diodati
Images courtesy of
• croweb • sundazed
• nickso • andy castro
• Graham • tkksummers
Ballantyne • spacesuitcatalyst
Editor's Notes
The problems with push
Image courtesy of croweb - http://www.flickr.com/photos/croweb/2904702979
Think about a typical COTS application. Users and their privileges are managed within the app and often there is very little in terms of remote user management capabilities. This has led to some of the complexities in user provisioning systems.
Traditional applications of federation technology follow two deployment patterns. The first is hub and spoke in which a heavy-weight company is the center of the federation and its trading partners federate on the hub’s terms.
Image courtesy of nickso - http://www.flickr.com/photos/nickso/3045996440/
The second federation deployment pattern is the network of peers. With no heave-weight at the center, the federation is composed of peers who federate amongst each other.
Image courtesy of Graham Ballantyne - http://www.flickr.com/photos/grahamb/2355477036/in/pool-324690@N20
Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
The problems with push in a federated environment: federated provisioning
Image courtesy of croweb - http://www.flickr.com/photos/croweb/2904702979
A variety of approaches have been taken to try and solve the challenge of federated provisioning.
One approach was to use SPML. First, not all service providers have an SPML interface. Second, not every enterprise has a provisioning process that can generate SPML messages.
Another approach is to use SAML. There have been two approaches to this. One is to establish an agreement that requires more than needed to perform authentication. This extra data is used back a backend provisioning process. The problem with this approach is that this data always is sent which can violate the privacy principle of data minimization among other things. The second approach is to use Metadata-Exchange to facilitate attribute exchange on an as-needed basis.
Cloud providers have been building their own provisioning interfaces using neither the SAML or SPML standards.
A few service providers have offered LDAP as a means of provisioning. In some cases, a provider can issue LDAP queries to the enterprise.
Needless to say, there is no one best approach. Or at least, there is no one agreed upon approach.
Same basic idea as cataloging entitlements.
These policies seem similar to provisioning policies but they have an extra clause - Context.
These policies seem similar to provisioning policies but they have an extra clause - Context.
These policies seem similar to provisioning policies but they have an extra clause - Context.
The above are example of contextual items that can be considered during an authorization event.
No single provider has close relationships with all the individuals a modern enterprise needs to deal with. So no organization can be a sole-source provider of low-cost, high-quality provider of all the identities an enterprise needs.
This is what a pull-based authorization systems looks like. A user initiates an action in a system that system asks the federated virtual directory (FVD) for all of the data needed to make the authorization decision. The FVD returns that data to the endpoint which makes a go/no-go authorization decision.
We’ll add another step to accommodate applications that don’t know how to ask for external information to make authorization decisions.
The XAMLoids know how to ask the FVD for information and then can present the go/no-go decision to the endpoint.
We expect SharePoint2010 as the “infection vector” by which claims-aware computing becomes popular in the enterprise.
To authorize people, the amusement park installs a sign at a given heigh.
Image courtesy of sundazed - http://www.flickr.com/photos/sundazed/555071016/
To authorize people, the amusement park installs a sign at a given heigh.
Image courtesy of sundazed - http://www.flickr.com/photos/sundazed/555071016/
That’s what a ticket is for.
Image courtesy of andycastro - http://www.flickr.com/photos/andycastro/2615845976/
That’s what the date on the ticket is for.
Image courtesy of andycastro - http://www.flickr.com/photos/andycastro/2615845976/
This is a great policy but it is awfully hard to audit.
Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
This is a great policy but it is awfully hard to audit.
Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
This is a great policy but it is awfully hard to audit.
Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
This is a great policy but it is awfully hard to audit.
Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
Consider you build the policy above.
Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
Someone arrives with a claim that looks like the above.
Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
This is the policy you meant to write.
Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
No single provider has close relationships with all the individuals a modern enterprise needs to deal with. So no organization can be a sole-source provider of low-cost, high-quality provider of all the identities an enterprise needs.
No single provider has close relationships with all the individuals a modern enterprise needs to deal with. So no organization can be a sole-source provider of low-cost, high-quality provider of all the identities an enterprise needs.
Data-intensive applications will require information to be “closer.” In these situations, the FVD and the endpoint can work with a cache or stash. Of course by adding a cache/stash, the chance that an authorization decision is made on “bad” or out-of-date data goes up.
The reality is that we will have push-only applications for long time. The hybrid approach of having both push and pull in the enterprise is the more likely future.
The Emerging Architecture of Identity Management - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1895
Market Profile: Identity and Access Governance 2010 - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1858
Characteristics of an Effective Identity Management Governance Program - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1731
Provisioning’s Role in the Next-Generation IdM Architecture - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1993
All images unless otherwise sourced where found on Flickr