As part of the BAE profiling and reference implementation, we have a full test & validation suite.  Our desire has always been to make the barrier to entry for anyone using the test suites to be the minimum it needs to be. As such we focused on creating our test suites using open source tooling so that we could provide a test suite project that an implementer could import into their open source testing tool, point it at their BAE implementation, run it, and get immediate feedback on whether or not their implementation was conformant to the profile.

To that end, we have been using the popular and free soapUI testing tool. Unfortunately, we are running into some limitations in the tool support for SAML 2.0. It would appear that the current soapUI implementation is using the OpenSAML 1.1 implementation and not the current OpenSAML 2.0 which supports SAML v2. In particular, this means that the following functionality that relates to the testing of SAML AttributeRequest/Response are not supported:

• Ability to digitally sign and validate attribute requests and responses using the enveloped signature method
• Ability to utilize the <saml:EncryptedID> as a means of carrying the encrypted name identifier
• Ability to decrypt the <saml:EncryptedAssertion> element sent by the Attribute Authority which contains the encrypted contents of an assertion

This has required us to go thru some gyrations in how we are implementing the test suites, which is making the user experience not as smooth as we would like.

Ideally we would love to continue using soapUI going forward, but we are also on the lookout for other open source tooling that we could utilize for our testing. Suggestions and recommendations from folks who have experienced this issue and have found a resolution would be very much appreciated.

I had the opportunity last week to visit with the Beverly Hills Police Department as well as their CIO and his staff. My areas of discussion with them were primarily focused around Information Security and Identity and Access Management.

Found them to be a very impressive organization, from the technical infrastructure they have in place, their desire to leverage information technology for the benefit of their customer base (both government and residents), as well as the partnerships that they have forged across many different arenas.

It was particularly interesting to hear the comments from them about how they are a sought after employer by some very talented people because of the very interesting projects that they work on and the technologies that they get to utilize. As a technologist, I definitely enjoyed their data center tour as well as an overview of upcoming capabilities that they are working on. Very cool stuff.

Funniest moment: Walking back from lunch with the Chief of Police. Waiting to cross the street. A young guy in front of us starts to Jaywalk! Instant shout from the Chief "Hey, Hey, What are you doing?" It was like watching the guy hit a rubber band. Instant backpedaling back to the sidewalk with an mumble that he thought the light was green. Punch-line: Chief is in business clothes. Not in uniform. Sheer authority in voice got the response!

P.S. Yes, please spare me the Eddie Murphy jokes; By now, I have heard them all

FIPS 201 defines a US Government-wide interoperable identification credential for controlling physical access to federal facilities and logical access to federal information systems.  The FIPS 201 credential, known as the Personal Identity Verification (PIV) Card, supports PIV Cardholder authentication using information securely stored on the PIV Card. Some PIV Cardholder information is available on-card through PIV Card external physical topology (i.e., card surface) and PIV Card internal data storage (e.g.  Magnetic stripe, integrated circuit chip). 

Other PIV Cardholder information is available off-card. Examples of off-card information, say in the First Responder & Emergency Response domain, could be certifications that could be presented by a Doctor or EMT that could verify their claims and allow physical and/or logical access to resources.

Accordingly, the federal government requires a standard mechanism for Relying Parties to obtain PIV Cardholder information (User Attributes), which are available off-card, directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Agency, which is the agency that issued the PIV Card to the PIV Cardholder.  The exchange of these User Attributes between backend systems is known as “Backend Attribute Exchange” (BAE). The architectural vision for the BAE can be found at IDManagement.gov (Direct link to "Backend Attribute Exchange Architecture and Interface Specification" - PDF).

I, and members of my team, have been part of a joint DHS and DOD team that have been working on a proof of concept implementation of the BAE in order to validate the approach, gain valuable implementation experience, and to provide feedback to the relevant governance organizations within the US Federal Government. The results of our work are three-fold:

1. A SAML2 Profile of the BAE, with both normative and informative sections, that provide concrete implementation guidance, lessons learned as well as recommendations for folks seeking to support this profile
2. Reference implementations stood up within the T&E environments of both DHS and DOD for interoperability testing
3. Test suites that can be used by implementers to verify compliance with the profile

I am happy to report that the profile is currently at v1.0 (DRAFT) status, under external review, and that we are scheduled to give a briefing on the work to a sub-committee of the Federal CIO Council later this month. In addition, we have our reference implementations up and running and are putting the finishing touches on the Test Suites.

As someone who has and is participating in industry standards efforts, I am fully aware that one of the critical items for a standard to become successful is for incorporation of the standard into vendor tooling. Some of the choices that we made, beyond satisfying the needed functionality, was to make sure that it was as easy as possible to build in profile support by:

• Not reinventing the wheel; Leverage the conventions and standards established by some of the fine work that has been done to date by the OASIS Security Services (SAML) TC on Attribute Query Profiles
• Keep the delta's as small as possible between the BAE Profile and existing profiles such as the X.509 Attribute Sharing Profile (XASP)
• Provide LOTS of informative guidance
• Striking a balance between making sure that the profile was generic enough to be widely used and deployable, but provided enough information in the message flow for implementers to get full value.

The last item was something that we found to be critical and sometimes contentious to balance. But, we would not be where we are right now, had we not been informed by our actual proof-of-concept implementations. A pure paper effort would have left too many holes to patch.

We have also made an active effort to reach out to vendors, especially in the federation, entitlement management and XML security arenas, and have been gratified by their response in committing to support this profile in their tooling (In some cases, folks already have beta support baked in!). We are fully expecting to highlight and point out those folks during our out-brief later this month. If you are a vendor, want to find out what it takes to support this profile, and are interested in receiving a copy of the v1.0 DRAFT, please feel free to ping me at anil dot john at jhuapl dot edu.

This has been a pretty extensive, exciting and detailed effort and we are very grateful for the senior level support from both Organizations for this effort.  Beyond that, it has been a blast working with some very smart people from both DHS and DOD to make this real.

Especially for those with young kids (This has now become a Christmas Eve tradition at our house) ...

Continuing a more than 50 year old tradition, NORAD (North American Aerospace Defense Command) will be tracking Santa on his Christmas Eve flight across the world. You and your kids can track Santa on NORAD's Track Santa web site.

A big "Thank You" to the men and women of NORAD, who have selflessly volunteered their time to personally update children via phone calls, emails and the Internet on Christmas Eve. Some further information:

• Why NORAD tracks Santa
• How NORAD tracks Santa

In another context, I was recently asked:

Since you first posted your article about interoperability, did you find out "Who among you actually implement this interoperable interface specification in your current shipping product?"

Thought I'd share the relevant bits of the answer that I gave:

"... before I answer your question, please know that the focus for my environment was/is on building out a policy driven infrastructure for a web services environment. And the motivations for going down that path include:

1. Consistent enforcement of policy (and in this particular case, access control policy) across multiple services
2. Minimize the number of interception points in the message path
3. Take the burden/complexity/headache of security policy out of the hands of the development teams who are deploying the services and move it into the infrastructure

As such, what I was particularly interested in having happen is for the XML Security Gateways in my environment to act as a XACML PEP to a remote XACML PDP. So to answer your question, you need to look at both the PEP and the PDP side:

One the PEP side, the answer is “It depends” on how flexible the product is. *Most* of the gateways provide you some mechanism for making an external “call-out” as part of the decision making process. i.e. Incoming request comes in to the PEP; PEP intercepts, does some basic threat and malicious content scanning, Authenticates the user/entity, then formulates an AuthZ request, sends it out in an “external call-out” to a PDP, and acts on the decision when it is returned.  The ease of how you can do this, and the ability to customize that call-out depends on the particular product. You basically have on one extreme the need to engage the consulting services of the vendor to customize that call, to the other of being able to have the ability to do-it yourself using nothing more than message templates.  So in short, you can bend the metal to make the PEPs generate a XACMLAuthzDecisionQuery and I am aware that at least a couple of the vendors in this space have it on the roadmap to be a native XACML PEP, but I am unsure of exactly what they mean by that term.

On the PDP side, what I will say is that silence as answer to the question is an answer in itself..   Pretty much all of the PDP vendors have some sort of a web service interface to their “Authorization Service”. To date my experience working with multiple products (both on the PEP and the PDP side) has been that you simply cannot point a PEP to PDPs implemented by multiple vendors and expect it to work without custom “franken-code” on either/both the PEP and PDP ends (Even though this was exactly the point of the Catalyst Demo that I noted in my blog entry).

These days my response to the vendor response of “Oh, Sure we do that!” is a request for a pointer to the WSDL and the XSDs of their  Authorization/Entitlement Service of their current shipping product to prove that they indeed do it. For some reason, the conversation seems to just die out at that point … <shrug>"

As always, if my understanding is incomplete or incorrect, please feel free to leave a comment on this blog entry.

What is the current state of interoperability between XACML PEPs and PDPs from different vendors? I am currently looking to see if there is a consistent implementation of PDP interfaces among the multiple Fine Grained Authorization/Entitlement vendors such that I can point a XACML PEP from one vendor to the XACML PDP of multiple vendors and not have to do custom integration to make it work.

Back in February 2007, Burton Group issued a challenge to the the industry to demonstrate interoperability of XACML. Some of the questions they asked were "Can enterprises really mix and match policy administration points (PAPs), policy decision points (PDPs), and policy enforcement points (PEPs) from different vendors? Is the XACML RBAC Profile practical? Or will we find that different interpretations of the specification yield less than satisfactory levels of interoperability?"

The industry responded, via the OASIS XACML TC, in June 2007 by having the first XACML Interoperability Demo at the Burton Group Catalyst conference. There were two particular use cases in this demo, which required interoperability between vendor implementations of PEPs, PDPs and PAPs:

• Authorization Decision Request/Response
• Policy Exchange

I am particularly interested in the first scenario and in looking at the interop scenario document, it would appear that some specific choices were made in order to make this work:

• Implementation of the XACML Interface of the PDP as a SOAP Interface which accepts a XACMLAuthzDecisionQuery and returns a XACMLAuthzDecisionStatement which are contained in the SOAP body.
• Use of the SAML 2.0 Profile for XACML 2.0 which defines a Request/Response mechanism for carrying xacml-context:Request and xacml-context:Response elements.

In effect, what you ended up with in order to make this work is the implementation of a standardized SOAP interface that adhered to the following Request/Response (Taken from the interop scenario document):

Sample SOAP SAML XACML Request wrapper:

Sample SOAP SAML XACML Response wrapper:

I attended this event and remember coming away impressed at the results while simultaneously amused at some of the coding heroics of the vendors who, if I remember correctly, in some cases had very short time frames to work with.

It has now been more than a year since this interop event and at this point I have a very simple question for the vendors in this space "Who among you actually implement this interoperable interface specification in your current shipping product?"

From what I see to date (and I am more than happy to be corrected on this point) is that while many vendors claim conformance and implementation of the XACML 2.0 standard, their PDP interfaces are still proprietary and unique. Oh, don't get me wrong, these interfaces may be implemented using web services etc. BUT each web service implementation is unique and special to that vendor and does not follow any consistent interface specification and as such is an integration exercise that is left up to implementers if you have PEPs from multiple vendors. e.g. XML Security Gateways or Software PEPs from multiple vendors which need to talk to a XACML PDP.

In the physical world, when an attacker is preparing to assassinate someone or bomb a target, the first thing that they will do is to determine how best to set up that attack. The phrase used to describe the initial phase of the set-up is called 'pre-operational surveillance'. 

Unfortunately, the default configuration of most web services allow a potential attacker to do the digital equivalent of pre-operational surveillance very easily. In the digital world, these type of threats are often classified under the category of 'Information Disclosure Threats'. There are two in particular (there are more) that I would like to call attention to:

1. SOAP Fault Error Messages
2. WSDL Scanning/Foot-Printing/Enumeration

1. SOAP Fault Error Messages

All too often, detailed fault messages can provide information about the web service or the back-end resources used by that web service. In fact, one of the favorite tactic of attackers is to try to deliberately cause an exception or fault in a web service in the hope that sensitive information such as connection strings, stack traces and other information may end up in the SOAP fault. Mark O'Neill has a recent blog entry 'SOAP Faults - Too much information' in which he points to a vulnerability assessment that his company did of a bank that provided information that enabled an attacker to understand the infrastructure the bank was running and presumably allowed them to further tailor the attack.

The typical mitigation for this type of information disclosure is the implementation of the 'Exception Shielding Pattern' as noted in the Patterns & Practices Book 'Web Service Security' [Free PDF Version] which can be used to "Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service's inner workings." (FULL DISCLOSURE:  I was an external, unpaid, technical reviewer of this book).

You can either implement this pattern in software or use a hardware device like a XML Security Gateway to implement this pattern. Mark utilized a Vordel Security GW, but this is something that can be implemented by all devices in this category. I have direct experience with Layer 7 as well as Cisco/Reactivity Gateways and happen to know that they support this functionality and I don't doubt that IBM/DataPower and others in this space support it as well.

Note that this does not imply that the error's that happen are not caught or addressed but simply that they are not propagated to an end-user.

2. WSDL Scanning/Foot-Printing/Enumeration

Appendix A of 'NIST 800-95: Guide to Secure Web Services' provides a listing of common attacks against web services, and you will note that there are many references to the information that can be found in a WSDL that can lend itself to a variety of attacks including Reconnaissance Attacks, WSDL Scanning, Schema Poisoning and more.

And in the 'Security Concepts, Challenges, and Design Considerations for Web Services Integration' article at the "Build Security In" web site sponsored by the DHS National Cyber Security Division, it notes that "An attacker may footprint a system’s data types and operations based on information stored in WSDL, since the WSDL may be published without a high degree of security. For example, in a world-readable registry, the method’s interface is exposed. WSDL is the interface to the web services. WSDL contains the message exchange pattern, types, values, methods, and parameters that are available to the service requester. An attacker may use this information to gain knowledge about the system and to craft attacks against the service directly and the system in general." 

The type of information found in a WSDL, and which can be obtained simply by appending a ?WSDL to the end of a service endpoint URL, can be an extremely useful source of info for an attacker seeking to exploit a weakness in a service, and as such should not be provided or simply turned off.

There are multiple ways of mitigating this type of an attack which include turning off the automatic ?WSDL generation at the SOAP stack application level or by the configuring the intermediary that is protecting the service end-point. For example, most XML Security Gateway's by default turn off the ability to query the ?WSDL on a service end-point.

I consider this to be a very good default.

When this option is implemented, there are often a variety of questions that come up that I would like a take a quick moment to address.

Q. If you turn off the automatic WSDL generation capabilities (i.e. ?WSDL) how are developers supposed to implement a client that invokes the web service?

There are two ways. (1) Publish the WSDL and the associates XML Schema and Policy files in an Enterprise Registry/Repository that has the appropriate Access Control Mechanisms on it so that a developer can obtain a copy of the WSDL/Schema/Policy Documents at design time. (2) Provide the WSDL/Schema/Policy files out of band (e.g. Zip File, At a protected web site) to the developer. 

Oh yes, there is always the run-time binding question that comes up here as well. What I will say is that run-time binding does not mean "run time proxy generation + dynamic UI code generation + glue code" but simply that the client side proxy and the associated UI and glue code are generated at design time, but that the end-point that the client points to may be a dynamic lookup from a UDDI compliant Registry. I've done this before and this does not require any run-time lookup of a web service's WSDL.

There is an additional benefit to this method as well. Have you ever gone through the process of defining a WSDL and Schema using best practices for web services interoperability, implemented a service using that WSDL and Schema, and then looked at the auto-generated WSDL? You may be surprised to find that the automatic generated WSDL may be in a majority of cases is not as clean or easy to follow and in some cases may indeed be wrong. The best practice for developing interoperable web services recommends following a contract-first approach. This requires that the "contract" i.e. the WSDL and the Schema to be something that is developed with a great deal of care given to interoperability. Since the automatic generation of WSDL is platform-specific, there is always the possibility of some platform-specific artifacts ending up in the contract documents, which is not what you intended to happen.

Q. What about those existing/legacy services that do a run time lookup? Won't those break?

The question that needs to be asked at this point is why these services are doing a run time lookup, is there value being added by this capability in this client, and are there alternatives that will enable the client to provide the same functionality without compromising security? 

As an example take the case of a BEA Weblogic client.  If you will look at the documentation that BEA provides on building a Dynamic client you will note that they provide two different approaches, one that uses a dynamic WSDL lookup and another that does not. The interesting thing about this is that the approach that uses the WSDL makes a run-time lookup of a Web Service's WSDL which will end up breaking if the ?WSDL functionality is turned off. But the alternative approach of building a dynamic client provides the same functionality without the run-time WSDL lookup.

From what I can see, from a functional perspective there is no difference between the two approaches and given that one of the things that you want to do when developing web services, or any software for that matter, is to minimize the number of external dependencies, I would choose the second option of NOT doing a run-time WSDL lookup in this particular case. What is regrettable in this case is that it appears that the default configuration in BEA's tooling is to use the run-time WSDL option (Or so I have been informed), which leads to issues when folks who choose the default options with their tools develop the clients. 

Mitigating these information disclosure threats requires both developers and operational support folks to understand their shared responsibility for security. Developer's need to understand that security should be part of the software development lifecycle and is not something that is bolted on at the end or is 'thrown over the wall' for someone else to take care of. Operational folks need to understand that a layered defense in depth strategy is needed and that secure coding practices of developers are an essential component of any operational environment. In particular the mentality of "Firewalls and SSL will save us all" needs to change for all parties concerned.

Digital ID World 2008 is the first IdM conference that I've gone to as part of a team, and given the variety of breakout sessions we decided early on to use the divide and conquer approach based on our areas of interest and expertise.

The following are some highlights on some (not all) of the sessions that I attended and found to be interesting. As with a lot of conferences, there were some sessions that were pretty much disguised vendor pitches which I am not even going to bother with a mention.

Keynote - Identity Assurance: A Backbone For The Identity Marketplace
by Peter Alterman - GSA, Andrew Nash - PayPal, Frank Villavicencio - Citigroup

In some ways this was rehash of the panel on the same topic that was moderated by Mark Diodati at Burton Catalyst but with the addition of Peter Alterman of the GSA, who tends to add a certain amount of ...ah... flair to the conversation

The intent of the Liberty Identity Assurance Framework (IAF) is to develop a framework that leverages the existing work that has been done by EAP, tScheme, US e-Auth etc. to generate an identity assurance standard that is technology agnostic but provides a consistent way of of defining identity credential policy and the process and policy rule set etc.  The IAF consists of four parts (1) Assurance Levels (2) Assessment Criteria (3) Accreditation and Certification Model and (4) Business Rules. You can find out more about it on the IAF Section of the Liberty Alliance Web Site.

What interested me about the entire conversation was the leveraging of OMB M-04-04 and NIST 800-63 to define the assurance criteria but the drive to make a "Liberty Alliance IAF Assurance Token" (if you will) that will be certified to mean the same thing across federations. Mr. Alterman also noted, and I hope that I interpreted this correctly, that the intent from the GSA side would be to not re-invent the wheel but to adopt this IAF framework going forward. He spoke of current inter-federation work he is involved in between NIH and the InCommon Federation that is leveraging this.

During the Q&A session, I brought up the fact that this work is directly focused on AuthN but in general, access to resources is granted based on a variety of factors, only one of which is the strength and assurance of the authentication token. The response is that the Liberty work is deliberately focusing on the AuthN and considers AuthZ to be out-of-scope for their work.

Keynote Presentation: State Of The Industry
by Jamie Lewis - Burton Group

Enterprise IdM is the set of business processes, and a supporting infrastructure, that provides identity-based access control to systems and resources in accordance with established policies.

• Business trends are driving integration across processes and folks are being asked to do more with less.
• SaaS is gaining momentum
Many failures in IdM projects caused by a lack of doing homework and a belief in the silver bullet product etc.

• People manage risk, not products.
• IdM is a means and not an end; It is about enabling capabilities and not an end in itself.
• The Identity Big Bang is around new ways of working, collaborating and communicating
• Make every project an installment on the Architecture and scope the goals to around 3 years.
• Always think about data linking and cleansing

That was the first half of the keynote, but the second half was something I found to be very fascinating and is based on work that Burton has been proposing around the idea of a "Relationship Layer for the Web"

• AuthN and AuthZ are necessary but not sufficient
• Centrism of any kind does NOT work
• Lessons from social science on trust, reciprocity, reputation etc.
• The future of identity is relationships
• Difference between close and distant relationships; Able to make many observations in a close relationship, so able to get good identity information. Not so for distant relationships
• A good relationship provides value to all parties. And it is not just about rights but also obligations
• Values like privacy etc. require awareness of relationship context
• Systems fail if they are not "relationship-aware"
• Difference between Custodial, Contextual and Transactional identities.
  -- Custodial Identity is directly maintained by an org and a person has a direct relationship with the org.
  -- Contextual identity is something you get from another party but there are rules associated with how that identity can be used.
  -- Transactional identity is just the limited amount of info that an RP (?) gets to complete a transaction e.g. Ability to buy alcohol requires a person to be over 18 (?) but in a transactional relationship, you would simply ask the question of "Is this person old enough to buy alcohol?" and the answer would come back as "Yes/No". Compare this to a question of "What is this person's age or birthday?" which releases a lot more info.
• The last type of identity in effect requires the existence of what Burton Calls an "Identity Oracle" (See Bob Blakley's blog entries) that has a primary and trusted relationship with a user as well as with relying party and can stand behind (from a legal and liability perspective) the transactional identity statements that it makes.

I found this entire topic absolutely fascinating as this is so very relevant to a lot of the work that I do around information sharing across organizations that may or may not trust each other for a variety of (sometimes very valid) reasons. Will be actively tracking this area on an ongoing basis.

The Plot To Kill Identity
by Pamela Dingle - Nulli Secundus

I really enjoyed this session by Pamela on the disconnect that currently exists between the needs of the users, what is being asked of the application vendors and the lack of a common vocabulary to express our needs such that there is a change in the same old way of doing business.

• Need for an effort to be consistent all the way at the RFP/RFI time
• Need a common vocabulary when requesting capability from vendors
• Start with:  Provide and Rely support i.e. the ability to choose whether or not a product relies on external identity services or provides its own.
• Pamela also had a great starting set of RFI type questions one can use.. I am hoping that she will post them on her blog.

One of the questions I brought up during the Q&A session was that if I bought in to the Kool-Aid of what she discussed during the presentation (and I do), what would it take to scale the conversation to a larger audience? Bob Blakley, who was also in the audience, chimed in and noted that if Pamela wrote up a white-paper on the topic, he would help her get it published and widely distributed as well.

I would also be very interested in expanding the scope of the sample RFI questions to be grouped by product/project category (and released under an open licence; Creative Commons?) so that folks like me can use them in our RFP/RFIs as well.

There were more sessions that I attended that were interesting such as the Concordia Workshop on "Bootstrapping Identity Protocols: A Look At Integrating OpenID, ID-WSF, WS-Trust And SAML", "Using An Identity Capable Platform To Enhance Cardspace Interactions" and more..

All in all, beyond the sessions themselves, the hall-way conversations and the connections made to be as valuable (or even more so) than just the sessions themselves. I know that I found and made connections with multiple folks who work in my community and am very much looking forward to future collaborations with them and others.

I am off next week to Anaheim, with the rest of my team, to attend Digital ID World 2008.  Very much looking forward to the event given its packed agenda as well as some already scheduled side-bar meetings.

This looks like it is going to be another one of my usual business trips that combines visiting some of the nicest/most-scenic cities on the North American Continent and spending all the time indoors in window-less conference sessions, which in turn leaves you with absolutely no time for any site-seeing

I recently came back from vacation to find that my primary desktop at home (a Dell Unit) was not booting up and the only indicator was a slowly blinking yellow power light.

After some investigation, it turned out that this was due to a bad power supply. On top of that, it appeared that the power supply fried the motherboard on its way to the land of no return. My first inclination was to buy another brand name computer. But in shopping around, I really was not happy with choices that were being offered, so decided to go the custom build route. 

Although I have built multiple computers in the past, I have not been keeping up with the current hardware esoterica, so got some recommendations from folks at work that led to a pre-built list of computer parts through the SlickDeals forum. An additional criteria was that since I had a copy of Windows Vista Ultimate lying around that I still had not installed on any of my systems, and since Vista SP1 had come out, I wanted this to be a machine that was capable of running Vista.

It took me 2-3 hours to put the system together on a Saturday with the additional benefit that it was a cool thing to do with the kids.

I am happy to note that all of the parts work together seamlessly, have full Vista driver support and once Vista SP1 and all of the latest updates were installed, I have a very smooth running machine.  While my Aero score was not at the top end, it still is enough to give me the full Aero experience with Vista (Per the Vista Help, the current base scores for the Windows Experience Index ranges from 1 to 5.9).

For those who are interested in building a very decently performing Vista compatible computer at a reasonable price, I have turned my list of parts into into a NewEgg Computer Wishlist for a Mid-Range Computer. My experience with this was very positive and I would recommend both the vendor as well as the parts.