Identity and Access Management

Identity Centric Architecture - 4 Part series By: Phil Becker

noreply@blogger.com (Prashant Kulkarni) — Mon, 04 Jun 2007 15:19:00 +0000

RBAC Profiles in the Solaris OS

noreply@blogger.com (Prashant Kulkarni) — Thu, 31 May 2007 19:41:00 +0000

Using Sun Java System Identity Manager With RBAC Profiles in the Solaris OS

Overview

The Sun Java System Identity Manager utilizes Resource Adapters to create, modify and delete accounts on systems running the Solaris Operating System. The Identity Manager Resource Adapter needs to be configured with a user that has access to perform user management tasks. The Resource Adapter for the Solaris OS can use the root account, the sudo utility, or a "privileged" user account.

Most customers will not allow Identity Manager to manage users with the root account. The use of the sudo facility requires installation and configuration on the Solaris OS. (sudo is a utility on the Companion CD that is not supported by Sun.) The creation of a "proxy" or "privileged" account is a secure way to grant fine-grained access to specific users. The Solaris OS has a built-in mechanism for delegating privileged commands to individual users or roles.

RBAC and Profiles

The Solaris OS provides Role Based Access Control (RBAC) for the delegation of administrative tasks. RBAC can be used as an alternative to using the root account for user management. RBAC is also a replacement for the sudo utility, which is not supported as a Solaris feature. This paper covers a component of RBAC called profiles. A given profile defines what privileged commands can be executed. A profile can be assigned to users and/or roles.
Profiles in the Solaris OS are enabled by having a user either su into a role or execute privileged commands in a "profile shell."
The Solaris OS provides three different profile shells:

/usr/bin/pfsh
/usr/bin/pfcsh
/usr/bin/pfksh

Click the link for the complete document. http://www.sun.com/bigadmin/features/articles/id_rbac.html

Identity Centric Architecture: True Robustness with Identity aware RIA and RTSJ

noreply@blogger.com (Prashant Kulkarni) — Wed, 30 May 2007 19:53:00 +0000

Identity Centric Architecture: True Robustness with Identity aware RIA and RTSJ

Disney-developed identity technology

noreply@blogger.com (Prashant Kulkarni) — Wed, 30 May 2007 08:36:00 +0000

This story appeared on Network World at http://www.networkworld.com/news/2007/052207-disney.html

Haapy Reading !!

Prashant

Start-up Bitkoo is releasing as a commercial product identity-management technology developed and deployed by The Walt Disney Co. that it says provides cutting-edge authentication/authorization and auditing/compliance capabilities. Bitkoo, however, isn’t just taking over commercial development of the technology that Disney calls Keystone। The start-up’s founder invented Keystone before leaving Disney.

Doron Grinstein, CEO of Bitkoo, brainstormed the idea and wrote the software for Keystone, which Disney has been using for nearly three years to protect access to many of its critical applications, such as the central reservation system at Walt Disney World in Orlando.
The Burton Group analyst firm last year called Keystone, “cutting edge” and featured a Disney presentation on Keystone at its annual Catalyst conference. The firm said Keystone’s ability to move authorization responsibilities away from applications “is one of the goals we have had as an industry for a number of years.”
Now the application, which handles nearly 10 million authorization requests per year at Disney, is available to the public.
Keystone provides a centralized engine that eliminates the need for authorization mechanisms to be built into applications. Applications and Web services written with tools such as Java, .Net, Delphi and COM need only a single line of code to turn their authorization duties over to Keystone.
Keystone’s access controls can be dialed down not only to secure individual applications but also to secure access to specific buttons, text boxes and functions within an application, as well as variables such as what times, from what IP address and under what conditions a user can access an application. In addition, auditing capabilities help organizations manage compliance requirements.
Disney, which is known for the quality of its homegrown technology, said late last year it was looking for someone to take Keystone commercial.
“I went to Disney and said the best place for Keystone is with its creator,” said Grinstein. “I have a great vision for it.”
That vision includes adding to Keystone 3.0, which Grinstein unveiled Tuesday at Interop, a new technology he has filed a patent for called “authlets.”
The authlet is a digitally signed piece of authorization data that can be as simple as where the user is located.
The authlets support what Grinstein calls federated authorization, a scenario where authlet information is temporarily stored on a client application or on a Web server via a Keystone client that runs on Apache or Microsoft’s Internet Information Server.
The client temporarily holds the authlets and when their data is needed to confirm access rights to an application or parts of that application the authlet serves it up without the client having to traverse the network to make the request at the Keystone server.
“This is much faster than going back to the network to see if something is allowed or disallowed,” says Grinstein.
The Keystone server generates an identity assertion, a series of authlets each containing one aspect of the user’s total access information. Keystone digitally signs each authlet and passes the entire assertion to the Keystone client agent.
“You can do any crazy authorization rule using Keystone and you never have to touch the source code of your application,” says Grinstein.
Keystone passes authentication duties, which validate the user’s identity, through its gateway to existing back-end systems, including Active Directory, LDAP-based directories and CA’s SiteMinder Web access management platform.
A centralized console provides a GUI interface for setting and administering policies on user access, and the database logs every authentication and authorization for future auditing and reporting chores.
Besides authorization and authentication services, Keystone has eight other modules including reporting, provisioning, administration, audit logging and audit reporting.
Bitkoo also is bundling with Keystone 3.0 its SecureWithin technology, which allows firewall-protected resources such as Web services and applications to be exposed only to authorized clients.
Bitkoo is shipping Keystone in four versions: an appliance that plugs into the corporate data center; a virtual machine guest installation; shrink-wrapped software that installs on Windows Server 2003; and a hosted service.
The starting price for a midsize installation is $100,000.

IAM Blog

noreply@blogger.com (Prashant Kulkarni) — Tue, 29 May 2007 20:17:00 +0000

I found recently that Ash' IAM blog is amazing..

http://identityman.blogspot.com/

Cheers,

The 7 Laws of Identity

noreply@blogger.com (Prashant Kulkarni) — Tue, 29 May 2007 15:36:00 +0000

I found this really cool article on Microsoft Technet, copied here for quick reference.

Happy reading !!

The 7 Laws of Identity

Digital identities have taken on an increasingly important role in the corporate infrastructure, as IT departments define what applications and data sources each individual user can access. But as the role of identities has grown, so has the complexity of identity systems. Since each application and resource typically has its own mechanism for handling authentication and authorization, managing this critical information can be a challenge. Fortunately, you can roll out a solution to simplify identity and access management within your organization. But before you plan your solution, you need to understand the seven laws of identity.

Chances are you're having an identity crisis, or will be soon. Identity and access management have become important components of every organization's infrastructure, but the complexity can leave you stymied. When you are designing security into your infrastructure, the worst thing you can do is assume you have to reinvent the wheel. The best thing, in actuality, is to take advantage of the knowledge and experience of those who have been through the process. There are some well-trod paths you can follow.

But implementation isn't the only facet of identity assurance. If you move up one level of abstraction, you begin to see some universal truths about the concepts surrounding identity itself and designing a system that will be strong, extensible, and trustworthy. It's always a good idea to make sure you're up-to-date on what others have discovered about security before you leap headlong into the fray. In particular, you should know about the Seven Laws of Identity.

The seven laws were developed by Kim Cameron, chief identity and access architect at Microsoft, and then refined in the blogosphere through his site.

The laws have been compiled and enhanced during an ongoing conversation among numerous people, and they represent the best available advice for architecting your identity solutions. Let's look at these seven laws and how they relate to real-life systems. Just to make sure you're paying attention, you'll be quizzed at the end of each section.User Control and Consent Technical identity systems must only reveal information identifying a user with the user's consent.
No matter what the circumstance is, the user must always have control over her destiny. If the user ends up not trusting the system, she will try to bypass it. It's as simple as that. The system must be clear about what information it requires and what it will do with the information.
This remains true in any context—even on the job. If you're designing an enterprise system, the right of first refusal must rest with the user, even if this breaks the conditions of employment. If set up this way, the employee is informed about how the information would be used, and the employer is indemnified by revealing all.

Question 1: Your company is designing a new system that will store a user's confidential reviews on a server in your main office. How should this system be designed?
A Users are required to upload their files to a site, with no explanation of where the files go
B Users are required to upload their files to a site, and they are informed that other users may have access to the information
C Users are required to upload their files to a site, and they're notified that the information can be accessed only by their supervisors and HR counselors
D Users are not required to upload their files if they don't want to; instead of placing their review on a remote server, they may play Solitaire on company timeMinimal Disclosure for a Constrained Use

The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution. Simply put, the less information you pass along to providers, the less information they can keep for future uses. And subsequently the less information that can be compromised. If a system uses your Social Security number as a sign-in ID and other systems do the same, you are uniquely identified across all these systems. That's identity theft waiting to happen, and, in fact, there are several laws proscribing the use of such identifiers. You're assured that the number is unique, but that strength is also its weakness.

Question 2: Complete the following message: "Thank you for signing up for free daily joke e-mails! In order to begin your subscription, we need your…"
A Home address
B E-mail address
C Cell phone number
D Social Security number and mother's maiden nameJustifiable Parties

Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship. Are you, as a user, aware of whom you're giving your information to and whether there's any reason for them to have it? This was the question many people asked about the Microsoft® Passport system—why would you give your information to Microsoft in order to access a third-party bookseller? What else was being traced? Were cross-site visits being compiled in some way? The actual answers to those questions don't matter. Once suspicions are planted in users' minds, they shy away from a single identity system. That's exactly what's happening in many countries and municipalities as governments debate issuing digital identities to citizens. It's one thing to use your government ID for government services. Would you really want to use the same ID to sign onto your personal e-mail account or do online banking, no matter how convenient that might be?

Question 3: Who is the best party to control the identifying information you've given to an online bookseller?
A The bookseller
B The government
C A third-party address-book site
D None of the above

Seven Rules in a Nutshell by Kim Cameron

Technical identity systems must only reveal information identifying a user with the user’s consent.
The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.
Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
A universal identity system must support both "omnidirectional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human/machine communication mechanisms, offering protection against identity attacks.
The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

Directed Identity

A universal identity system must support both "omnidirectional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. Directed identity is an extension of the public/private key setup. A public entity is omnidirectional, broadcasting its existence for all to see. A private entity, like a user, is unidirectional. You should always know how to find a particular Web site, because it broadcasts its existence by way of its URL. But Web sites should not be able to follow you around. (Some affinity marketers disagree with this, which is why Internet Explorer® lets you reject third-party cookies.)
In the physical world, systems like Bluetooth and RFID currently have problems with the Law of Directed Identity. An RFID tag is omnidirectional—anyone with an RFID reader can sense the tag's approach. If one of these tags gets into your passport or driver's license, you'll be broadcasting information about yourself to anyone with the mechanism to pick it up. At best, this is probably a nuisance; in certain situations (traveling abroad, for instance), it could be downright dangerous. Any identifier should respond only when it can be certain that the reader is trusted.

Question 4: Which of the following choices is an example of a unidirectional identifier?
A Your Bluetooth adapter signal
B A Web site URL
C A building-entry swipe card
D The microchip that was secretly implanted in your arm when you were vaccinated as a child

Pluralism of Operators and Technologies

A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers. Context is always important in identification. While we can dream of a single, all-encompassing ID system that works in all contexts, the vast differences in purpose among roles makes this impossible (not to mention undesirable). You don't want the same system to provide both your office e-mail and your personal e-mail, because you have different privacy expectations for each. For this reason, a good identity metasystem will allow for components that offer divergent—and sometimes contradictory—features. While a metasystem can adopt a single protocol, and even a consistent user experience, the actual identity providers will vary depending upon whether the user is acting in the context of a consumer, an individual, an employee, or some other role. If you think about what XML has become—the same structure is used to syndicate content, to store user settings, and to provide inter-process communication—it becomes clear that identity metasystems can act similarly, providing a basis for whatever functionality vendors need to provide.

Question 5: How many operators should be able to work together with a universal identity system?
A 1
B 3
C 47,559
D As many as necessary

Human Integration

The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human/machine communication mechanisms, offering protection against identity attacks.
The Internet seems more dangerous than ever, but in reality it's becoming more secure. We understand attacks better now, and administrators are more attuned to the concept of preventative maintenance. But all the antivirus programs in the world can't keep a user from clicking on a link in a phishing e-mail, thereby inadvertently authorizing an attack on his machine. The same goes for identity. You can protect communications with all the 128-bit keys you want, but the easiest way to commit identity fraud is to steal identifiers right from the user. That's why human integration is so important to a successful identity metasystem.
A system that works is one that's clear to the end user and that can be shown to work effectively. Is the user experience unambiguous? Can the user make informed decisions from it? ID systems don't end at the keyboard, they end at the individual—and systems must take this into account.

Question 6: Why do hackers target the end user rather than the in-process communication?
A The end user can be tricked into opening a fake message from a bank and entering info
B If the hacker can assume a user's identity, he also gets to keep the comfy office chair, stapler, and travel coffee mug
C Communications protocols can be effectively secured, and the end user is the weak point on the chain
D All of the above (except maybe B)Consistent Experience Across Contexts
The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
Take a look in your wallet. Chances are you have a large number of cards. One might be a driver's license; another a student ID. You might have a couple of credit cards, an ATM card, a library card, a health plan card, and maybe even a supermarket "rewards" card.
You can think of your wallet as an identity metasystem. It holds identification as physical objects, and you are probably comfortable using each card you get. Each one identifies you, but each card is used in different contexts and has different capabilities. One lets you borrow books, while another buys your groceries.
Different people have different combinations of cards, depending on the various contexts they need to access. Creating a consistent ID experience across contexts works the same way in an identity metasystem. Depending upon what context you're trying to access, the relying party may ask you to provide one or more cards to prove you are who you say you are and you have the rights you're asserting. You need to understand which cards do what, but you know you can always ID yourself as long as you bring your wallet.

Question 7: Which of the following is not a common contextual identity choice?
A Browsing (self-asserted identity for exploring the Web)
B Community (public identity for collaborating with others)
C Citizen (identity issued by a government)
D Credit card (identity issued by a financial institution)
E Klingon (self-asserted identity for visiting a sci-fi conference at the local VFW hall)
ID Management

For more information on Identity Management, visit the following online resources.

The Identity Metasystem
Design Rationale Behind the Indentity Metasystem Architecture
How Microsoft Does IT: Identity Management
Conclusion
Why are these seven laws of identity so important? Digital identities play a key role in today's information infrastructure. If users and companies do not see identification as safe, private, and secure, the lack of trust will end up undermining any products and technologies that are built upon it.
To keep up on the ever-evolving world of identity systems, you should definitely get Kim Cameron's Identity Weblog in your aggregator. You can get the feed at www.identityblog.com/?feed=rss2, and you'll get several interesting articles every week. These will give you a better picture of the important work going on in this area.

Question Answer

1. Your company is designing a new system that will store a user’s confidential reviews on a server in your main office. How should this system be designed?
C. It is a condition of employment to create and file a review. Users can choose whether to do this, but not complying violates company policy. At the same time, they are given concrete information that clearly explains the exact boundaries for their personal information, so they can feel confident that prying eyes will not get to it.
2. Complete the following message: “Thank you for signing up for free daily joke e-mails! In order to begin your subscription, we need your…”
B. You only need an e-mail address to send out e-mail. If this is a real service and not just some trick to get your home address, nothing more is or should be required. Forms that ask for all sorts of personal information create an atmosphere of distrust.
3. Who is the best party to control the identifying information you’ve given to an online bookseller?
A. People have high levels of trust in the entities they’re dealing with directly, and less trust in third-party go-betweens.
4. Which of the following is an example of a unidirectional identifier?
C. A swipe card only works when you choose to swipe it. In contrast, a Bluetooth adapter announces its existence indiscriminately to all in the vicinity. A URL lets any visitor find their way to your site. And we won’t even get into what that microchip does.
5. How many operators should be able to work together with a universal identity system?
D. An identity system is best defined through its underlying protocol and user experience, providing extensibility for any valid operators who want to plug into the system.
6. Why do hackers target the end user rather than the in-process communication?
D. The human at the end of the identity system is the path of least resistance into the system. Systems should be designed to minimize confusion and ambiguity for the end user.
7. Which of the following is not a common contextual identity choice?
E. At least, we hope that’s the answer.