Unfortunately, the data used to justify this proclamation is flawed at many levels.

Disclosure: I am the architect of the XACML 3.0 PDP authorization engine at the heart of the Dell/Quest Authorization Policy Server product, and I am a member of the OASIS XACML technical committee. I am a Dell employee, but the opinions stated here are my own, not my employer’s.

Cser writes:

Lack of broad adoption. The standard is still not widely adopted with large enterprises who have written their authorization engines.

Setting out to write your own authorization engine makes as much sense as writing your own operation system or your own encryption algorithm. Authorization is a complex topic. Rolling your own security system for each application is not a good use of resources, nor a good approach to security in general. For businesses savvy enough to recognize this, there is no shortage of capable authorization engine products available on the market today, most of which support XACML either natively or through an interop transform.

Inability to serve the federated, extended enterprise. XACML was designed to meet the authorization needs of the monolithic enterprise where all users are managed centrally in AD. This is clearly not the case today: companies increasingly have to deal with users whose identities they do not manage.

Wow. Where’d that come from? XACML has absolutely nothing to do with Active Directory, nor user identity in general. I’ve helped customers design XACML policy systems that weren’t dependent upon user identity at all.

A business can write XACML authorization policy rules that test for user identity metadata such as roles, group membership, or attribute values stored in Active Directory. If the business runs multiple AD domains, then they should be careful to write their policy logic in a way that spans their AD domains.

A better solution would be to move away from the central directory model into a claims based model so that the XACML policy rules evaluate security claims about the user submitted with the authorization request. SAML is one mechanism to securely convey user claims. OAuth can carry user claims as well, via token formats such as JWT. When user attributes and claims are presented with the user identity in a XACML authorization request, the XACML PDP can make fine-grain authorization decisions involving user identities from different domains of control. The PDP need only trust the issuer of the user attributes and claims and verify that the cryptographic signature on the user data comes from a trusted issuer.

PDP does a lot of complex things that it does not inform the PEP about.If you get a ‘no, you can’t do that’ decision in the application from the PEP, you’d want to know why. Our customers tell us that this can prove to be very difficult. The PEP may not be able to find out from the complex PDP evaluation process why an authorization was denied.

XACML does provide a mechanism for the PDP to communicate such information to the PEP – Advice. All the business security officer writing policy has to do is attach an Advice element to a policy rule to return information or messages to the PEP and application. Example: If the disk-quota-exceeded rule evaluates to Deny, an Advice element attached to the rule can return a message to the PEP like “You have exceeded your disk quota of {N} MBytes.”

Other responses to this criticism of the tight-lipped PDP returning only a terse Permit or Deny authorization decision:

• “It’s none of your business”
• “That’s classified”
• “It’s not the PEP’s role to ask why. It asks for permission, it gets a Permit or Deny.”
• “The decision involved other people’s personal data which is not appropriate to disclose to you.”
• And my favorite: “Divulging the details of the factors that led to this decision can be exploited to construct targeted attacks to circumvent the security system”

A PDP can be configured to have access to back-end data that the client application is not trusted with. Returning this data with the decision would present a significant breach of security. The PDP defaults to returning only the authorization decision itself with no supporting data because this is the most secure option for all cases. A policy writer can opt to add Advice elements to rules to selectively disclose data to the PEP about the decision.

Granted, it is useful to have full disclosure of what’s going on inside the PDP when you are debugging a security policy that isn’t returning the authorization decisions you wanted. That’s outside the XACML spec and left as an exercise for the vendors. Because debugging the internal state of a PDP is inherently tied to the implementation details of the PDP, this isn’t a strong candidate for standardization because every implementation will be different.

When you put your PDP and policies into a production environment, you will turn off everything related to debugging.

Not suitable for cloud and distributed deployment. While some PEPs can bundle the PDP for faster performance, using a PEPs in a cloud environment where you only have a WAN link between a PDP and a PEP is not an option.

Wow. Another “Where did this come from?” A PDP should be a stateless service, which makes it ideal for scaling up to thousands of PDP nodes in the cloud to handle any amount of load. With every PDP instance running the same set of policies, so it doesn’t matter which PDP instance the PEP talks to: they’ll all give the same authorization decision for a given request.

If you’re looking at a PDP that cannot be hosted in the cloud or cannot be scaled up through replication because of some statefulness issue, you need to look for another PDP product.

When considering where to place a PDP service relative to an application, it helps to think of the PDP authorization service like storage. Would you implement a cloud hosted application that consumes data stored on your private corporate network? In most cases, probably not because the round-trip latency would drag your app responsiveness down. You’d locate your storage in the same data center that hosts your app so you have fast and easy access to the data – and no data bandwidth costs or quotas. In special cases where the data is too sensitive or too large to be uploaded to the cloud, taking the performance hit to remotely access the data residing on your private network may be more acceptable than the general case.

The same is true of other services your cloud-hosted application relies upon, including authorization. In most cases, it makes the most sense to locate one or more PDP servers in the same data center that hosts your app. The PDP servers may need to occasionally get policy updates from your corporate network, but these are relatively rare events and won’t affect service availability. The use case of having a cloud based app always calling into your corporate network for authorization would be extremely rare/unusual, requiring a mountain of extenuating circumstances to justify.

Commercial support is non-existent.

A curious statement considering the Forrester article opened with a mention of a commercial authorization product (Quest APS) which supports XACML and includes PEP libraries to facilitate application development. There’s no shortage of other commercial XACML PDP system vendors as well.

I suppose the fact that one of the largest network router makers uses XACML as part of their router security policy authoring system doesn’t count as commercial support for XACML. Or Boeing, or major banks and brokerage houses. I suppose the fact that the US Government (Defense Information Systems Agency JPES) requires XACML conformance in new systems doesn’t count as commercial support either. That’s the public sector, after all.

It’s true that you won’t find a PEP enabled shrink-wrapped software product in stores today. External authorization doesn’t provide much benefit for consumer applications installed at home (yet*). Large enterprises generally don’t send an intern out to pick up a 10,000 seat software product at OfficeMax. We shouldn’t judge the health of the business software industry by what you find on the shelf at the local office supply store.

(*)With the rapid acceleration of the rise of the machines the “Internet of Things” (tiny devices all through your house or office that communicate with each other over TCP/IP networks) authorization and access control in the home environment is going to become a big issue very soon.

Refactoring and rebuilding existing in-house applications is not an option.

It’s true. It’s hard to convert an application built long ago on the premise that it makes its own authorization decisions based on its own internal authorization policy logic into something that defers those decisions to an external authorization service, where policy can be changed rapidly without requiring a redeployment of applications.

You can avoid the cost of refactoring in-house applications by committing development resources to implementing corporate policy logic in each application in your organization, to updating each of those application every time corporate policy changes, and to deploying those updated applications in the field.

This will be much less expensive than refactoring for external authorization, so long as the number of applications you’re responsible for is less than 2, your corporate policy changes less than once annually, and/or all of your users reside in the same building.

OAuth supports the mobile application endpoint in a lightweight manner XACML today largely supports web based applications. While OAuth’s current profiles are not a full-blown replacement for XACML functionality, we see that OAuth’s simplicity made it the de-facto choice for mobile and also non-mobile applications.

Apples vs oranges here. OAuth doesn’t provide fine-grain authorization. OAuth doesn’t provide external policy evaluation either. OAuth is a lighter weight response to things like SAML which can convey identity and user attributes in a secure manner. OAuth is a communication protocol to pass authorization data around securely. XACML is a policy evaluation system that produces authorization data.

You can use OAuth with XACML. You can use OAuth authorize a PEP to make requests to a PDP, or to convey user identity & attributes to the PDP as part of an authorization request. But since OAuth and XACML are fundamentally different things in the authorization stack, one cannot replace the other.

Yes, OAuth’s relative simplicity has enabled OAuth to trump SAML, particularly in the consumer web application space (Google, Facebook, Twitter, etc). That’s hardly a criticism of XACML. If constructing XACML authorization requests in XML is too difficult on your mobile device, then use the XACML REST and JSON profiles instead.

I hope you find these data points useful, and I look forward to Forrester learning more about XACML in the future. ;>

I noticed suspicious behavior in the IP access logs of one of my web sites a little over a year ago. I turned on logging of failed login attempts to get a better picture of what was happening.

I checked the logs a bit later and was shocked by what I found. Thousands of failed login attempts against one WP site in only a few hours. And there was only one user for the site – me! Login attempts were coming in at a rate of 2 to 3 per second from a fairly small number of IP addresses.

What spooked me most was that all of the login attempts were for the same user account name – “admin”.  Which also happens to be the default admin account name for a WP installation.

It was pretty clear that someone was running a script of some sort attempting to “brute force” guess the password for the admin account of my WP web site.

You can and should make sure all your account passwords have sufficient complexity and length to fend off brute force guessing.

Having a strong password isn’t the end of the story. You can do better than just making it “very difficult” to guess your password. You can completely cut off the attacker’s ability to make password guesses by deleting the default “admin” user account of your WP site.  If you don’t have an “admin” account, then they can’t log into it.

Before deleting your WP “admin” account, be sure to create a new WP user account with full admin rights, and give it a nonobvious username. Don’t use your published “contact me” email address. Log into your site as this new admin account, and then delete the default “admin” account.

There are many levels of defense you should consider implementing for any web site, including possibly a smart firewall to automatically block rapid and repetitive traffic from the same IP address, but the first step to reduce the risk of someone logging into your site using the default “admin” account name is simply to delete the “admin” account.

Not only did disabling Windows Firewall not resolve the Windows Update issue, but Windows Firewall would not restart! I mucked around with it for a bit, and then put the whole machine aside for a rainy day repaving.

More recently, I decided to see what this Windows 7 Homegroup thing was about. Set it up on a few machines on the home network, and… nothing. Everybody’s on the same homegroup password, and at least a few machines are sharing folders with the homegroup, but nothing shows up in the homegroup list.  Digging around in one machine turned up an error starting the Homegroup Listener service. Probably important for listening to other homegroup members, eh?

It turns out that the Homegroup Listener service requires the Windows Firewall service to be running. And wouldn’t you know, this is the machine that can’t start Windows Firewall.

A little more investigation led me to this thread about Windows Firewall system error 6801. In amongs several guesses was this note from “DPTower”:

FIXED IT! - For all having this specific problem, please follow these steps!!
Open a “run as administrator” command prompt.
Go to “c:\windows\system32\config\TxR” (or the equivalent location on your PC)
- run “attrib –H –S *” to make all hidden files in the directory visible.
- run “del *.blf”
- run “del *.regtrans-ms”
- reboot the machine

This didn’t sound like your usual pundit taking wild guesses, and the answer had been voted up many times by others. So I gave it a try. Deleted those files, rebooted the machine, went to enable Windows Firewall, and boom! It started!  Hazaah!

Up next: catching up on 2 months and 200MB of Windows Updates.  And while that’s cooking I’ll poke at this Homegroup thing some more.  (Is it true that Homegroup doesn’t play well with IPv6? What genius dreamed up that limitation? My entire home network is IPv6!)

It has been a busy year or so. I joined BiTKOO in October 2010 to help expand and scale BiTKOO’s push into the nascent XACML external authorization space.

14 months later, Quest Software acquired BiTKOO in part to fill a gap in Quest’s identity and authorization management offerings.

Now, less than a year after that, Dell has acquired Quest Software. Quest’s people and products will help Dell establish a strong presence in the enterprise software and services market, particularly in the identity and access management space. Dell brings to Quest an enormous increase in sales force and customer contact, which translates into a huge bump in software revenue and resources for further technology development. Quest is great for Dell.  Dell is great for Quest people, Quest products, and Quest customers!

I expect we will continue executing on Quest product cycles and technology roadmaps uninterrupted through the Dell integration process over the course of the next year or so.

I look forward to engaging with my new Dell colleagues to solve identity and authorization challenges for our new Dell customers – and beyond!

But, if you take your time you can melt glass in any shape of kiln so long as it  can reach the required temperatures and hold at specific temps for long periods of time. Glass slumping, fusing, and casting actually require lower kiln temperatures than firing clay ceramics, but you have to maintain those temps a lot longer than for ceramics.

So one weekend I decided to give glass bottle deconstruction a try. Since this was primarily a test of material and kiln performance, the shape wasn’t particularly important. I grabbed a cylindrical mold I had printed in Hydroperm plaster on my Z406 3D printer. I print these little dishes up by the dozen to use as single-use crucibles for material testing in the kiln. Today that material would be recycled bottle glass.

I grabbed a green wine bottle from the recycling bin, wrapped it in a heavy canvas, and gave it several good whacks with a hammer.  (Hint: start by breaking the neck of the bottle first, then work up to the body).

I filled the mold with glass shards, standing most of the large pieces on edge to pack them in tighter and to reduce the chance of air bubbles getting trapped inside. Less than a third of the bottle’s glass went into this slug.

The kiln firing schedule for glass is very different from firing clay ceramics. Glass needs to be heated and cooled much more slowly than clay to avoid thermal shock. Glass can soak up a lot of heat energy, but it is a very poor conductor of heat. Most of my kiln firings for clay take less than 24 hours to ramp up and cool back down. For this small glass slug, the firing time was almost double that. Glass pieces that are inches thick at the core can require many days of kiln time, mostly for the controlled cooling and annealing soak times.

Molten wine bottle glass in a plaster mold. Temp is about 1500F.

After firing the mold becomes a crumbly powder – still strong enough to hold its shape against the weight of the glass, but a half-inch thick wall will easily crumble when pinched between thumb and forefinger. Demolding the piece is easy – just brush with a whisk broom.

After demolding, there were a few sharps that needed to be ground down. Most were on the top side of the glass, where glass had stuck to the side of the mold and left a thin razor edge shard sticking up from the edge of the disk. A few minutes at the grinding wheel took care of that.

The slug is a little more than half an inch thick. At that thickness, green bottle glass is nearly black except when strongly lit from behind. A thinner casting would show more color with ambient light.

Love that depth of character and complexity

I love the complexity of “stuff” going on inside the slug that’s revealed when held to the light. This would work well for sconces and other back-lit or interior-lit thingamabobs.