–

Attendees

What is mean by identity oracle?

* An oracle provides an answer to a question but not a specific attribute

** If you ask an Oracle, is Peter over 21 it says yes. It [...]]]> These are my raw notes put here for reference purposes.

–

Attendees

• Peter A
• Mary R
• Ian G
• Gerry B
• others

What is mean by identity oracle?

* An oracle provides an answer to a question but not a specific attribute

** If you ask an Oracle, is Peter over 21 it says yes. It does not hand back an attribute – birthdate

Peter: The Federal Govt is authoritative for very few attributes – State Dept – passport #, citizenship. State govt are authoritative for driver’s license number. SSA for SSN.

eVerfify is an example of an oracle, says Gerry.

Peter – what will drive this is the requirement for LOA3 credentials needed to access to medical records.

P – “We do not have an attribute infrastructure.” A lot of attributes are simply issued via IdP’

I – our examples so far have shown organizations that are authoritative for identifiers but not attributes

P – raises need for back end attribute exchange

Gerry – Problem with authoritative attribute provides is that the PDP makes a decision as to what is truly authoritative for a given context. Authoritative data source must provide SLA or MOU so that relying party can establish trust.

P – BAE is 1/2 of the equation and attribute provider (market?) is the other half

A – is there a business model for attribute providers?

G – have problems seeing attribute exchange at enterprise scale let alone government scale. Quality and availability are just some of the issues. Access decisions are fairly local and these decisions are not things that known often at the higher enterprise layer. Things are made authoritative by policy decision.

P – Second model for authoritative – a local decision to assign authoritative-ness to something

Nishant – should we get rid of the term authoritative?

Peter for sees multiple attribute providers having say over the same attribute for the same person

If I use an Oracle, do I have to know its sources? No, says Gerry, as you form an agreement with the Oracle ahead of time as to what happens when something goes wrong

P- I am running validation services which services 400 back-end apps. I am standing up a BAE to help. I could build that infrastructure or I could can contract out to an Oracle. The Oracle has to tell me its sources so I can make a decision to use it or not. Gerry comments that you may not want to know the Oracle’s source of data.

Returning to the eVerify system – is a person allowed to work? eVerify doesn’t disclose sources of info but DHS takes responsibility for its decisions.

Pam asks about redundancy of providers. Redundancy allows same decision to be made via separate paths.

Anil feels that there is a business case for multiple providers.

Mary raises the point that there are organizations who have a lot of data on people. These are often highly regulated organizations because they are related to financial services.

G – uses Health Vault and Google Health as an example of multiple providers of heath information data

A – Talked to financial roundtable – these ors not interested in B2C but very interested in B2B situations. Having the govt offering services to help vet people would be of great service.

Govt business for providing identity information? There are certainly companies that will aggregate public data for a fee. If a service provider helps get me as a business information I need to hire someone (citizenship for example), would I use it? Would I form a business to do this? N raises BT’s You Are You service as an example of this.

Pam – talking about building cloud-services in this area. Definitely interest from small business for federation and using Google as authoritative source. Sees consumer-focused needs later down the road.

I asks P about persisting “over 18″ information if it is acquitted from Equifax. P says they’d have to issues SORN and protect as PII.

I am curious about about Govt as Oracle and the implications with respect to the Privacy Act. Peter wants to facilitate market for Oracles. NIH had MOU with InCommon which included use of attributes and information. This included agreed upon protections for those attributes which was coherent with InCommons users’ requirements. Peter acknowledges this doesn’t scale but he offers as a counterpoint that NIH is doing this federation to federation. He asserts there wont be that many to federate to.

I many not want to maintain a BAE with hundreds of connections to attribute providers. Likely outsource the work to an Oracle. “It is easier to affiliate with a hubs than it is affiliate with each provider,” says Peter A.

Peter says that NIH sees need to to handle attributes and thus NIH is setting up BAE. He acknowledges that there needs to be policy and practice around this, which Peter is on the hook to build. FICAM roadmap says that if you are standing up an attribute service it must be a BAE if you want funding.

G – If I am a BAE affiliate and I want to consume other affiliate’s data, what is the quality I can expect? Anil says that this is currently being discussed amongst architecture groups. G talked about the quality within his organization. There is no strong commitment to the data that internal data collectors collect. At the end of the day if something goes wrong, is it my fault or someone else’s. THis is part of the contractual relationship between data consumer and provider.

Hold Harmless clause within MOUs used the by the PKI Bridge. So long as org is acting in accordance with their own policies then they are to be held harmless. G – in certain situations this works, but in others it does not. I might have to run my own infrastructure or shop for another provider who can back up their assertions.

Pam asks if this is govt to govt discussion, would a private group come in an provide services for G2G? Anil says yes and that currently this is happening.

Because there are so many million of high level of assurance credentials, one would think that someone would want to build an ecommerce infrastructure to consume these creds – says Peter.

Peter asserts authentication is a solved problem and next up is authorization, claims, roles, etc.

Every application owner want to maintain control over who comes into the app. But this a way that Peter gets people to plug into the federated SSO environment.

Are people building services to consider risk-based authorization in transaction, asks Pam. Anil mentions the consideration of environmental attributes for initial authorization. G says this is a hot space now. Anil brings up how PayPal takes a low assurance cred and uses it for financial transactions.

At any rate, we are 7 days away from Burton Group Catalyst EU! In the 7+ years that I’ve been involved in one way shape or form with Burton Group, I’ve never been to a Catalyst [...]]]> I’ve been a bit quiet on Tuesdaynight lately… sorry – it has been a bit crazy around here lately.

At any rate, we are 7 days away from Burton Group Catalyst EU! In the 7+ years that I’ve been involved in one way shape or form with Burton Group, I’ve never been to a Catalyst EU – so I am very excited. For those of you joining us, you are in for a treat – John Seely Brown will delivering the keynote for us. Besides Mr. Brown, the IdPS team has got some great content waiting for you:

• Bob will kick things off with a look to the future identity architecture
• I’ll be talking about the IdM market as a whole
• Lori and I will have a serious conversation with our dear friend – provisioning

Fun for the whole family…

For those of you not heading to Prague, follow the conversation on Twitter. We’ll be using the #cat10 for the conference and the identity conversation will be on #idps.

See you there either in person or virtually…

My hope is that the overall ICAM initiative is successful—not because I have [...]]]> A friend in the industry recently asked me for my thoughts on OpenID, InfoCards, and the US federal government’s work to consume non-government issued credentials. Letting the question rattle around in my head for a while, here’s what I’ve got so far.

My hope is that the overall ICAM initiative is successful—not because I have been eagerly waiting to interact with the federal government using some form of authenticated credential—but because we (citizens, enterprises and government) are at a pivotal moment in the history of the web. With the US government working with both the OpenID and InfoCard Foundations, there exists an opportunity to change how individuals interact with large organizations, both public and private. For the first time, individuals would be able to (even encouraged to) interact with a large organization (such as the US federal government) using an identity asserted, not by the large organization, but by the individual. In this case, the State is no longer the sole provider of identity. This breaks the monopoly that the State has had on credentials and is indicative of the future to come.

But there is a long road to walk before getting there. There are numerous concerns with these plans. Among these are notable security concerns, especially with OpenID, that the identity community is not blind to. These are not my primary concerns.

My primary concern is with the establishment of standard user behavior that could prolong existing problems. Today, after decades of enterprise training and a decade of consumer training, people naturally expect to see two text boxes on web sites. One is for their username and the one with the little stars is for their password. This behavior is ingrained. Changing this behavior is no small feat – just ask the OpenID and InfoCard groups. But it is a change that must occur to normalize people using something stronger than username and passwords to authenticate themselves.

My concern is that the behavior that is being established as a norm – the use of either an identity selector or some other user interface means – will become the username/password for the next generation. This isn’t a hypothetical problem; the writing is already on the wall. Currently, OpenID will only be accepted for low-value transactions with the government known as Level of Assurance 1 (LOA1). Activities like filing tax returns requires a far greater assurance that the person is who they claim to be and thus require a Level of Assurance 3 identifier. And there is problem. The way people use an LOA3 credential may be very different than how they do so with an LOA1 credential.

If we, as an industry, normalize user behavior that meets LOA1 needs but not LOA3, we are training in behavior that has to get untrained in a near future. What the government and its partners are on the path to doing is effecting real cultural change. This kind of change doesn’t happen often and is hard to do, and especially hard to undo.

I definitely want a future in which I can assert my own identity without validation from the State, but I am very willing to wait for that future to assure that the behavior the industry normalizes is one that will work for generations to come.

(Cross-posted from Burton Group’s Identity blog.)

Entitlement management is simply fine-grained authorisation + XACML

I have four problems with this.

First, definitions that include a protocol are worrisome as they can overly restrict the definition. For example, if I defined federation as authentication via SAML, people [...]]]> Ian Yip’s take on access management versus entitlement management can be partially summed up with this equation:

Entitlement management is simply fine-grained authorisation + XACML

I have four problems with this.

First, definitions that include a protocol are worrisome as they can overly restrict the definition. For example, if I defined federation as authentication via SAML, people would quickly point out that authentication via WS-Fed was just as viable as a definition. So in terms of an industry conversation, we need to make sure that our terms are not too narrow.

Second, I fear that this definition is a reflection of products in the market today and not a statement on what “entitlement management” is meant to do.  Yes, most of today’s products can use XACML. Yes, they facilitate authorization decisions based on a wider context. But who’s to say that these products, and the market as a whole, have reached their final state? Along these lines, I wonder if externalized authorization stores are a required part of an “entitlement management” solution?

Third, there is something missing from the definition – the policy enforcement point. A fine-grained authorization engine provides a policy decision point, but that still leaves the need for an enforcement point. This holds true whether an application has externalized its authorization decisions or not.

Finally, I have a problem with the phrase “entitlement management” (just ask my co-workers). As I have blogged about before, Kevin and I have been in the midst of a large research project focusing on role management. One of the things we have learned from this project is that enterprises do not use the phrase “entitlement management” the same way we do.

A bit of history – three or so years ago Burton Group, at a Catalyst, introduced the phrase “entitlement management” to include the run-time authorization decision process that most of the industry referred to as “fine-grained authorization.” At the time, this seemed about right. Flash forward to this year and our latest research and we have learned that our definition was too narrow.

The enterprises that we talked to use “entitlement management” to mean:
·      The gathering of entitlements from target systems (for example, collecting all the AD groups or TopSecret resource codes)
·      Reviewing these entitlements to see if they are still valid
·      Reviewing the assignment of these entitlements to individuals to see if the assignments are appropriate
·      Removing and cleaning up excessive or outdated entitlements
More often than not, we found that our customers used “entitlement management” as a precursor to access certification processes.

Using a single term (“entitlement management”) to span both the run-time authorization decisions as well as the necessary legwork of gathering, interpreting, and cleansing entitlements can lead to confusion. The way enterprise customers currently use “entitlement management” works well to describe how legwork is vital to the success of other identity projects.  (I’ll be working on a report this quarter that delves deeper into this.)

I am all for a broader conversation on fine-grained authZ versus entitlement management. And as Ian Yip has pointed out on twitter, identity blog conversations have dropped off a bit and I’d love to stoke the fire a bit.  But we can’t have meaningful conversations without shared definitions. So what’s your take? What do you mean when you say “fine-grained authorization” and “entitlement management?”

(Cross-posted from Burton Group’s Identity blog.)

Nishant has commented on my post about federated provisioning.  He has provided two different examples of federated provisioning.  One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning.  In this case, Nishant agrees with me that provisioning of this sort is [...]]]>

Nishant has commented on my post about federated provisioning.  He has provided two different examples of federated provisioning.  One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning.  In this case, Nishant agrees with me that provisioning of this sort is no different than provisioning the UNIX box down the hall.

But it is Nishant’s second example, the just-in-time provisioning example, which is a bit tougher.  In this case, the enterprise and its service provider have a federation in place.  Using SAML-based authentication, a new user attempts to access the service provider’s service.  The idea (hope?) is that the service provider recognizes the new user request, provisions the user, and authenticates the user in the same conversation. Nishant does add a degree of difficult in this scenario as he ties the federation service to a provisioning service.  Grabbing attributes from the SAML token, creating a SPML message, and handing that to a provisioning service is possible, but as a commentator points out this sort of interop isn’t spec’ed out so the heavy lifting is left to the service provider.  And even if the service provider doesn’t want to directly link its federation and provisioning services, it still needs to grab that assertion attributes and create the account in the backend system. 

It turns out, to my surprise, that there are people doing this.  Parties in a federation agree to which attributes are needed and send those in their authentication assertions.  A process at relying party uses those attributes to provisioning new accounts.  This is a fairly lightweight and effective approach, but there are some catches to be aware of.

The first catch, as Nishant points out, is if the service provider needs attributes above and beyond what are in the assertion, there’s not an easy way for the service provider to ask for them.  To deal with this, the service provider has to present a registration screen of some sort to the user.  Compared to the first scenario in which the federate account is already waiting for the user, the second scenario is herky-jerky and will annoy/confuse the end user.

The second catch is deprovisioning.  The provisioning process hinges on an authentication event.  Deprovisioning cannot be activated on de-authentication.  This does leave the problem of how to remove accounts when people have left a federation partner.  In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login.  After some period of time without an authentication, the account is suspended or deleted.  Not a bad way to go.

JIT Provision may in fact be “real” federated provisioning, but not provisioning, as a dogmatic, dyed-in-the-wool provisioning guy would immediately recognize.  While I take my dogma for a walk, this quarter Lori and Bob are going to looking into some of the intersection point of identity management and SaaS and I think they’ll have more to say on this type of conversation in the coming months.

This is an interesting wrinkle in an ever-changing market.  CA now possesses a preventive-controls engine with the ability [...]]]> Yesterday CA announced its acquisition of IDFocus,  a small Israeli company.  Among other abilities, IDFocus provides a finer-grained segregation of duty (SoD) analysis engine.  CA has previously integrated this engine into Identity Manager, their user provisioning tool.

This is an interesting wrinkle in an ever-changing market.  CA now possesses a preventive-controls engine with the ability to look further into the security stack of an application.  This engine allows customers to make SoD decisions below the role or group level, at the lower ACL/security object levels.  Provisioning vendors have until now done this by calling external services provided by Enterprise Application Controls Management (EACM) vendors.

On one hand, CA has partially obviated the need to integrate with an SAP, Oracle, or Approva by integrating the IDFocus capabilities into CA Identity Manager.  On the other hand, CA’s move may have made things more confusing for customers.  By increasing the number of controls repositories that a customer has to maintain, integration of IDFocus makes compliant provisioning deployments more challenging.  What would be really slick is if CA could find a way to work with the EACM vendors to synchronize SOD tests so that a customer could use the same test for both detective and preventive applications.

I was speaking on this very topic in Europe last week.  I commented on the various architectures for integrating EACM into user provisioning to provide compliant provisioning services.  (For more on this subject, check out Lori’s report on the matter.)  CA has now introduced a fourth deployment model in which the provisioning engine owns the entire compliant provisioning event from the request through the SoD test to the provisioning event itself. An interesting alternative. I’ll be curious to see where CA takes this.

(Originally post on Burton Groups’ IdPS blog.)

This step is the [...]]]> Matt Hamlin, over at Sun, mentioned a conversation we had last week about a topic in identity management which doesn’t usually get a lot of airtime: the correlation of accounts to people.  The exercise is the first step in answering Matt’s simple question of “Who has access to what?”  Matt writes:

This step is the foundation for Access Certification, Role Mining, Entitlements Management, Policy Evaluation, Identity Auditing, and numerous other custom services developed by our customers.

There were two major omissions in his list: password management and user provisioning.  The reality is the correlating of accounts to people is a requirement for all identity management exercises.  This correlation isn’t glamorous work and isn’t a one time affair.  None the less, it is crucial “Identity Gold” for identity management projects, but also as the foundation for risk mitigation exercises as well.

Here’s a tip to enterprises out there – ask your software vendors and deployment teams what capabilities they have to help facilitate this correlation.  Ask early and before you start down the path of an identity project.  Make it an on-going process governed by your overall identity management program.

I’ll be touching on this a bit in an upcoming Telebriefing I am doing.  On October 1st and 2nd, I’ll be giving a sneak peak of my research on access certification and will cover this and other topics.  If you are a Burton Group subscriber, you should check it out.  If you aren’t a BG customer, you should become one.  ;-)