CHAPTER 11
Authorization: Now That I’ve Got It, How Do I Get to It?

Little pig, little pig, let me in.

—The wolf in the story of the Three Little Pigs

You don’t really log in to an application in order to be handed the keys. Authentication is just the first step. You have informed the framework as to who you are, which is fine. But now it must take that information and match it against established policies in order to govern what actions you are able to perform after that. This is called authorization. The difference between authentication and authorization is subtle. Think of it this way.

When you authenticate, you’re going to the coat room and handing in your claim check.

The hat check girl gives you your coat and hat, which are your identifying features.

The valet recognizes you because of the coat, so he authorizes you to get your car back. Back home, the dog recognizes you because of the hat, and authorizes you to enter your home without getting bitten.

Got that? Authentication says to the system, that’s John Smith, and here are his attributes and group memberships and roles. Based on those, authorize him to actually use his stuff.

Layers of Authorization

There are multiple levels to authorization. The deeper you go, the more detail you can apply, and the more you can segment policies and users. It’s the difference between “Bob and Alice can get in, but Ted and Mary can’t” and “Bob and Alice can get into this part of this thing, but Ted can only get half of that, and Mary can see it but can’t do anything with it.” Sometimes security professionals refer to this as “defense in depth,” meaning multiple layers give you more insulation. Both the downside (forensically) and the upside (security) to this is that all it takes is a single “nay” to disallow an action. If your firewall, WebGate, and behavioral filter all say “come on in,” but your fine-grained entitlement engine says “no,” the result is that you don’t get what you want.

Perimeter security is as broad a protection as it gets. Firewalls, VPNs, and network access control are all great for deciding who’s in the club. It’s the first line of defense, and it can keep out plenty of riff-raff. Sorry, we’re not really covering that stuff here.

NOTE

A gentleman in charge of perimeter security at a banking customer informed me that the largest number of attempted IP hacks came from Russia, with Romania close behind. Foreign hackers have little fear, since they’re anonymous, often trolling by way of other people’s IPs, and they know that unless they cause severe material damage, they’re beyond law enforcement. But perimeter security handles the vast majority of these attempts, so I’m not downplaying its importance; it’s simply not the subject of this book.

Coarse-grained security gives you protection of that next inside ring, the windows to your applications. Gates or agents on the web servers interact with administrative servers to perform authentication and far more granular authorization than the perimeter. Here you can associate groups of users with groups of resources. You can even examine individual users if you wish (not recommended), and start pulling apart URIs for even greater granularity. You’re also able to discern sufficient detail about a user (as an individual and as a member of a group) to provide personalization. “Welcome back, Joe, here’s your customized menu and a list of your last three purchases.” Of course, even at this level, it’s still considered coarse-grained access control. While it can handle the bulk of your authorization requirements, it is not easily configured to consider the context of the transaction, the environment, the time of day, the method of authentication, and so on.

Context-based access considers all factors, not just who is asking for what. You’re looking at how users got there, from where, and when. It can even look at their historical behavior, to find possible anomalies. It also logs a user’s current behavior, lumps it in with past behavior, and continues building a profile for future authorization decisions.

Fine-grained access occurs at the application level. Now beyond even the URI, security is analyzing the specifics of a request, behind the web server. You could still plug in at the web server, but better yet at the application server, or the code itself. Even if you find yourself in the unenviable position of having to embed security within the actual application, you are still externalizing the policies and relieving your programmers of the burden of maintaining actual security code. They’re simply providing an opportunity for fine-grained entitlements control to do its job within the app.

Let’s stop one more moment on coarse versus fine-grained entitlements. Coarse looks at who you are and the thing you’ve asked for. It can be made to drill down a bit further, but that’s not its primary function. Still, it handles the majority of your authorization requirements. Fine-grained and behavioral authorizations make decisions based not just on the who and the what, but also the when, the where, the how, and even combinations of these. You might then say, why wouldn’t you always put fine-grained access in place? Because anything that does more work will always require more work. The policies for coarse-grained authorization could be as simple as this:

ou=AR,ou=accounting, o=MegaBigCorp gets/accounting/receivables/*.*

Everybody in the organizational unit or group gets everything in the folder, based on the broad abstract of the policy. Fine-grained access definitely requires more thinking, more planning, and more maintenance.

I’ve been asked this question twice in the last year: “If users are only provisioned to those resources they’re allowed to have, why do we need authorization? By default, doesn’t anybody who approaches an application need to be enabled anyway?”

In theory, the answer is yes. But provisioning is mostly providing the context by which a user enters an app or accesses a resource. There are multiple reasons why you still need both provisioning and authorization:

You still want that decision-making layer in case provisioning activity lags behind security policies. Provisioning may be decided by group (or attributes), but it is at its core an individual-user activity, while authorization is more often than not a group decision. If policy changes are made that affect an entire group, they may not bubble down to the provisioning/workflow activity immediately, in which case authorization is your safety net.

In addition, provisioning policies are security- and compliance-minded, certainly, but those are secondary to the business context they truly have. You get access to a resource because you need it for business reasons. But you are authenticated and authorized for security reasons. These components, provisioning and access, are often governed by different parties, and for a very good reason.

Provisioning says, here you go, you’ve got it. It doesn’t say, you can have it any day of the week, any hour of the day, or from any IP address anywhere in the world. Authorization manages access based on configurable conditions.

Just as with provisioning and authentication, you provide authorization in an externalized layer for two primary reasons: to enforce consistency in your security policies, and to take the burden for security off the shoulders of your developers so they can concentrate on the business logic.

Commercial, off-the-shelf apps in general don’t have the ability to enforce fine-grained, rules-based policies.

Authorization provides the framework for real-time Segregation of Duties (SoD), which can be enforced during execution (and which we will discuss in greater depth in Chapter 12).

Regardless of the solution layer you’re looking at, you can simplify the types of authorization rules into two groups, allow and deny. This is true of all the models we will discuss in this chapter. In some solutions, the same rule may specify both possible conditions, while in other solutions, these may be two different rules. The point is that you can create conditions that specifically allow or deny access to a user if he meets the qualifications. You may have heard the terms “positive model” and “negative model.” Same idea. If you have a single rule consisting of both conditions, and a user doesn’t qualify under either, the result is a deny.

“Allow” rules are easier in that they’re inclusive. “Out of a hundred groups, everybody in Group #3 can have access” is far simpler than “I’m going to deny everybody in Group #1, Group #2, Group #4, and so on.” Deny rules are useful, however, when you have definite targets to exclude from access, such as internal versus external users. Deny rules that exist under a blanket allow rule are usually termed an “exception-based policy.”

Quite often, Active Directory is used for managing local security policy, domain security policy, and domain controller security policies, and it can do this by organization or group. It can manage access to actual computers just fine. But it can’t really lock down applications in a meaningful, business-facing fashion without extending the schema and then enabling the apps themselves to take advantages of those extensions. Group memberships themselves don’t provide enough granularity or context to differentiate between types of users within the same group or organization. If I have a hundred users in accounting who have access to a set of resources through a Group Policy Object, but I want to provide senior-level access to ten of them, do I configure my access control lists? Do I create a sub-ou just for seniors, spreading out my users and making my structure more complex? And will the accounting chief have any idea how to do this, or will she just ring her IT bell and yell for help? Active Directory is obviously quite ubiquitous as a corporate directory, but should be considered just a component in an overall identity and access framework, not a corporate security mechanism. It also has a tendency toward proliferation of groups, which we’ll also discuss in detail later.

Let’s look at how the different kinds of authorization policies work, and how they help keep the business secure and compliant.

Coarse-Grained Authorization

In the previous chapter, we discussed how Oracle Access Manager provides the authentication component for your IAM framework. It also provides a high level of authorization for simple association of groups of users with groups of resources. It bases this level of security on policy domains that specify the rules governing how a given set of resources are to be protected. Remember that policy domains define the resources to protect, the rules and expressions for protecting them, the policies for resource subsets, and delegated administration configuration. Within a policy domain, you associate groups of users with groups of resources, but you can toss in mitigating circumstances such as day of the week, time of day, and user’s IP address.

Resources aren’t just target applications or files. A resource in this context includes the target, as well as the operations you can execute against it:

For HTTP resources: GET, POST, PUT, TRACE, HEAD, CONNECT, OPTIONS

For EJB resources: EXECUTE

For databases: ADD, DELETE, UPDATE

By using AccessGates, you can also protect other non-HTTP resources. There are prebuilt integrations allowing protection and SSO with JSPs, servlets, SAP, WebLogic, WebSphere, and other endpoints.

Groups can also be expressed in multiple ways, such as role or directory group, which can be a static group, nested group, or dynamic. Quick digression: a dynamic group is normally constructed on the fly by query (such as “everybody with a current balance of more than $5000”) and may be supported natively by your user directory.

The same infrastructure that provides authentication services also provides authorization, meaning the WebGates, AccessGates, and Admin Server described in Chapter 10. Once a user is authenticated and identified, his profile, memberships, or other attributes can be matched up with the conditions and the resource being requested to determine if he is allowed, per the policy domain for the resource, to attain access.

Coarse-Grained Protection of Web Services

Oracle Web Services Manager (OWSM) also has the ability to act as a Policy Enforcement Point (PEP) in providing coarse-grained authorization for web services. In other words, OWSM supports high-level authorization rule enforcement, without the need to insert code.

“RESTful” web services are used for managing resources over HTTP, in which the noun, or identifier, for the resource, is generally stated as a URL, URN, or URI. This means that OAM has the ability to protect these resources in a coarse-grained fashion.

True Story

When I was selling one of the earliest access management tools involving web server plug-ins several years ago, a customer asked, “What happens if your plug-in, or the policy server it connects to, goes down?” I asked what he would like to have happen. “I’m afraid my users will get locked out. I’d want the thing to get out of the way.”

I said, you’re exactly correct, they’ll be locked out, but no, you don’t want it to get out of the way. If your security framework stops functioning, you don’t want the users outside getting in with no policies in place to mitigate their actions. Of course, this situation should not occur, which is why some genius way back when invented redundancy.

Authorization Rules

On the previous page we discussed how it’s possible to set both allow and deny conditions on a resource. In Oracle Access Manager, a single rule can specify both conditions. The conditions themselves specify which users qualify. Here’s who is allowed, here’s who is denied. If a user comes calling on the resource, and qualifies for neither condition, then by default she is denied. For the user portion of the rule, you can specify

The machines from which a user can access the resource

The acceptable days and hours during which the resource can be accessed

An LDAP group or filter for which the user must have the proper criteria (good)

A role the user needs to have (even better)

A specific user (maybe not so good)

If you’re creating rules for specific users, hopefully you’re not doing too much of it, since that doesn’t really scale, does it?

You can aggregate one or more OAM authorization rules (possibly mitigated by an operator) into an authorization expression. A user may need to meet the conditions of multiple rules within an expression in order to gain access. Remember what I said: It only takes one “no” to deny access. It is the same with rules. Failure to qualify for a single rule means a denial.

A policy domain, with which you associate one or more resources, contains a single authorization expression.

A rule itself does more than just allow or deny. There are many situations in which you may want to provide a qualified yes; that is, I let you in, and while I’m at it I’m going to perform a redirect based on your role or group or attributes. Of course, it is often just as simple as, “you asked for it, you’re qualified, and here you go.” But in a deny situation, you almost always want to take some kind of action. You don’t want a generic message, a “page not found,” or an “access denied” message. The framework should be a babysitter of sorts, which includes accounting for even the failures. This gives a greater appearance of control, and a better user experience. If I can’t have something, tell me why, or send me to a place where I do have access. Therefore, in addition to allow and deny conditions (who qualifies), and timing conditions (when they qualify), and a general description, an authorization rule also contains possible response actions:

Setting HTTP header variables and/or cookie values, typically to be used by the target resource

Redirects

The headers can be used for personalization or other purposes. The redirects can be used to send a user to a friendly landing page. In the event of an authorization failure, the user should be directed to a page that says, as nicely as possible, “You don’t get in.” In these situations, it’s advisable to give a user some options. If you can identify that user as someone who should definitely not be there, you might make it a warning page. However, even for a success, it can be very useful. Besides personalization, consider multiple tiers of users (for example,. silver, gold, platinum) all using a common URL, but being sent to their respective landing pages. The framework in this way augments the business logic. Developers simply need to provide the landing spots, while OAM gets the users to the right ones.

Using headers or cookies, you can pass a user’s distinguished name (DN) or profile information, along with static text. Remember that when you consider the entirety of variables and cookies, you’ve got 4K to work with. Also remember that a major function of OAM is single sign-on. Header variables are perfect for passing data that downstream apps need for authentication.

I mentioned operators that mitigate how rules can work together. They’re actually very simple: AND and OR. For example, if you wish to limit access to a particular group who can only touch the resource from the office, the expression might look like the following illustration.

It’s also possible to create more complex rules, such as the equivalent of

(HR-Group AND Allowable-IP) OR (External-Auditor-Role)

An extremely useful tool within OAM is the Access Tester. With this interface, you can simulate all the necessary conditions to test the authentication and authorization rules for a policy domain without having to actually launch an application or page, essentially acting as your own client. With Access Tester, you specify the URL to hit, the operation to attempt against it (for example, PUT, POST, and so on), the IP address to simulate coming from, the date and time, and the user(s) to simulate. You can optionally choose to see which policy and rule get fired off. You will hear from some people that this is a great tool to use before putting policies into production. Let me qualify that. This is a great tool to use before handing your framework over for regression and load testing that precede production, and which we’ll discuss in Chapter 15.

Extending the Authorization Model

Oracle Access Manager also provides an authorization API with which you can build custom authorization plug-ins to provide decision making not readily available in OAM. This may include making use of third-party logic or data sources not supported out of the box. Bear in mind, when you’re doing so, you must be careful not to overdo it. The more information you can retrieve from the user directory itself, the better. In Chapter 15, I have a lovely story about how an integrator wrote so much custom code using an access tool’s API that it added a minute and a half to every login. The more layers you pile on, the more latency you can potentially add as well.

Basing Authorization on Risk, Activity, and Behavior

In the previous chapter, we discussed the use of Oracle Adaptive Access Manager for the creation of patterns or buckets with which to monitor user activities based on resource, point of origin, time, trends, and so on. At the risk of being redundant, the same types of challenges that are used for stepped-up authentication challenges also apply here for authorization. When activity is judged as entailing enhanced risk based on behavior, the result as generated by OAAM can be a denial of access.

Presuming a user has already been authenticated, the framework must now monitor actual activity, not limited to simply the choice of resources but also how those resources are used. Even if potentially risky authentication has been approved (such as a known user authenticating from an unknown IP or device), the flow of activity may flag the user as being at odds with policy, leading to a denial or additional challenge. The risk models and weighted scores that drive authorization within OAAM may evolve over time (and in fact they should). We will cover the evolution of those models in Chapter 13.

Within OAAM, you can define a transaction (which is any process or series of tasks that a user can perform once he’s authenticated) as a group of elements, and use that transaction entity as the basis for fraud analysis and authorization. With standard coarse-grained authorization, you may allow a user to post the contents of a page. With OAAM, you might map the contents of that page as a transaction, and decide, based on the values of the elements, that the post cannot take place.

Despite the seeming granularity of this action, this is still to some degree coarse-grained authorization because the elements of the transaction are still mapped to the client, with the decision making all based on values available before they are posted to the application itself. True fine-grained authorization is enforced with the Oracle Entitlements Server.

Fine-Grained Entitlements

A typical web app is a three-tiered model: browser interface, a web server behind the first firewall, and the actual business logic behind a second firewall. Coarse-grained entitlement security makes decisions on access before a request even makes it to the application layer, which is a good thing. Not only does this take the burden of security away from developers, it takes the strain of making security decisions off the app server. But when it comes to making those security decisions, the security mechanism can only decide based on the same elements that the web server itself can see. Once a request disappears behind the DMZ, visibility is gone. In most organizations, this level of security is sufficient, and for the majority of security requirements, it will be sufficient for some time to come (except in the financial industry, where fine-grained access control and web services security were effectively born).

But with increasing regulatory requirements, the trend is to move some aspects of security closer to the resources themselves. To this end, Oracle has increased the number of options it has for securing the database and the users who access it. But before the database, there is an application layer that can also be secured. This is what fine-grained entitlement management is all about. These elements are considered fine-grained because of the components being protected: database objects, business objects (transactions, reports, accounts), user interface components, and server-side transactions.

Oracle Entitlements Server authorizes activity on business objects beyond the reach of the web server. Like coarse-grained authorization, it can take into account conditions such as request origin and temporality, but then can make use of additional elements accessible only to the business logic, then enforce authorization decisions at that logic level. It is also more suited to being embedded with the logic, either in the code itself or, when possible, with the app server, to provide a more easily maintained, externalized layer of security.

An OES security model is similar to that of OAM. It consists of:

Resource (app component such as page, portlet, bean, submit button, and so on)

Action (grant, deny, delegate)

Privilege (user actions that may be executed)

Subject (role, group, user, system)

Constraint (user, time/date, groups, attributes)

A policy can cover any application and the components that make up that app. When a request is made to that application, by either a user or process, the policy evaluates the request based on attributes related to the system, transaction, user, role, group, or the resource itself. And as with OAM, a user may be considered as an individual, as a member of a group, or as someone assigned a particular role. In fact, the user could be evaluated as a combination of those factors (for example, allow any user with the role of Claims Adjuster and belonging to the group location-London).

Consider this example. Doctor Howard can look at his patient’s records. When Doctor Howard refers certain of his patients to a specialist, Doctor Fine, only the records of those particular patients can be viewed by Doctor Fine, and only the relevant parts of those records. If Doctor Fine is asked by Doctor Howard to examine a patient’s broken leg, Doctor Fine doesn’t necessarily need to know that the patient was taking Viagra four years ago. If the patient himself can review medical data by way of his health plan’s website, he can only view his own records.

Quite often, a fine-grained decision is based on a transaction that is initiated not by a user, but on behalf of a user by a service account. A service call may be initiated based on the requesting user’s credentials, or the calling process or service using the user’s context simply to validate that user’s permissions. Identities may be provided over HTTP/S, JMS, or even IIOP (everybody remember CORBA?), and represented as simple user tokens, Kerberos tickets, X.509 certs, or increasingly as SAML assertions. Although OES does not support SAML 2.0 protocol, it does support SAML 2.0 providers, and can use attributes from a SAML token, which can be retrieved in multiple ways.

Just as the ammunition for making authorization decisions in OES is more fine-grained, so is your ability to define resources. There may be a hierarchy of components within the application (app, servlet, Enterprise JavaBeans [EJB]) as well as for the logical entities of the business logic. A business object could be a purchase order, invoice, financial account, and the like. You can therefore apply a hierarchy of rules to create a baseline for a policy, along with the cascading variations to cover the levels of the hierarchy. Imagine a set of mutual funds managed by an office. Regular funds for the average investor may have a transfer limit, transfer approval requirements, and a number of qualified managers. As the funds get larger and/or more diverse, the transfer limits get larger, the requirements more strict, the number of qualified managers smaller.

Consider the resource tree shown in the following illustration. With a policy written for the highest level in the tree, the children can inherit the policy. Here you can also see a list of all policies associated with any given resource. This allows you to drill down on the granular details of what authorizations are taking place.

Just as with OAM, the OES admin console contains a simulation tool for testing the policies for an application before that application is even available.

OES also allows for run-time delegation of rights between users, assuming that policy evaluation determines that both parties are permitted. This type of action cannot be easily accomplished except at a fine-grained level.

OES Architecture

In an ideal situation, Oracle Entitlements Server will plug into the supporting architecture for the application in order to intercept, evaluate, and generate responses to requests. A significant portion of the time, this means attaching to the application server. Let’s look at this ideal situation, and some not-so-ideal situations. But first, let’s examine where OES sits in the infrastructure.

Like other access control structures (such as OAM), Oracle Entitlements Server has a hierarchy of components through which it provides fine-grained protection:

Policy Administration Point (PAP), or Administration Server, which includes an interface for creating and maintaining resource definitions and policies; it is supported on WebLogic Server, Tomcat, and WebSphere, and provides full delegated administration capabilities.

Policy Decision Points (PDP), which are distributed components for receiving policies from the Admin Server and evaluating requests against those policies.

Policy Enforcement Points (PEP), which are agents that plug into app servers or web servers; the PEP intercepts the request and queries the PDP for a decision on how to enforce policy and which actions to take in response.

Failover allows PDPs to switch over from a down PAP to a secondary.

Together the PDP and PEP are defined as a Security Module. The security modules also serve as the touchpoint for user authentication, single sign-on, and any external attributes that must be evaluated as part of a policy. In OES, it’s common practice, and in fact Oracle’s preference, that the PEP and PDP be configured side by side for the sake of performance. Web service calls between the two could go out at a rate of 700 per second in a normal configuration, but with an embedded PDP, that can scale to 7000 per second. A more centralized PDP configuration, with multiple PEPs per PDP, can provide a less costly infrastructure, although the latency can be higher.

The PAP pushes policies out at intervals or in real time, as configured, to the PDP. If the communication between the two goes down, the PDP operates off the last known policies until communication is re-established.

To centralize the administration of enterprise-wide policy sets, while still segregating applications by line of business, OES supports the concepts of Applications and Organizations. Each organization might contain multiple applications whose policies must be kept separate.

In the past, application servers made use of Java Authorization Contract for Containers (JACC), in which a third-party security mechanism provides authorization data to the app server for application security. It’s largely an all-or-nothing security blanket, without consideration for multiple roles for a user, for example. In fact, the JACC spec doesn’t provide much guidance for mapping users to even a single role, and there is nothing to provide context for a particular request.

More common these days is the Security Support Provider Interface (SSPI), although many vendors are denigrating their SSPI support. SSPI also has limitations when it comes to context. OES eliminates the need for both SSPI or JACC by providing far greater functionality and granularity, on top of GUI-driven policy management.

It may not always be possible or desirable to deploy a PEP. This may entail embedding calls to the OES engine for policy evaluation directly into the code. However, even this type of implementation can still provide great benefit to developers, and minimize the amount of labor typically associated with embedded security logic. By simply calling out to OES with the transaction parameters necessary for policy evaluation, developers can avoid having to code the complex logic required for most fine-grained security decisions. Consider the following example:

Any required changes in the policy, which could possibly affect multiple code chunks, require only a centralized change through the OES PAP interface. Whether the policy is embedded or not, the interface for maintaining the policy remains the same, as in the following example:

The design you put into fine-grained policies requires a different mindset. You need to consider the business transactions themselves rather than just the interfaces to them. Similar to the way you need business and IT people to come together in order to map business roles to nested roles, fine-grained entitlement protection requires that business and IT people come together to map out the guts of your most critical transactions. Even if you provide fine-grained policies for some of your transactions, that doesn’t mean you have to cover everything. In fact, it’ll be nearly impossible anyway. You’ll need to choose which transactions require this kind of security, based on criticality. You will choose two types of transactions: the ones you need to secure, and the ones you want to show the auditors that you’ve secured. A lot of the time, these will overlap. Sometimes they won’t.

Authentication is mostly non-incremental, meaning you will provide some kind of authentication to everyone from the very start. Authorization policies might be incremental in that you may apply more stringent requirements as time goes on. Fine-grained protection will most definitely be incremental, at least for legacy applications. But going forward, it is highly advisable that you provide a way for developers to expose a transaction map for applying fine-grained policies at launch.

One last benefit of the Oracle Entitlements Server: It can enforce fine-grained access control on data sets returning from Oracle database queries, by using the Oracle Virtual Private Database (VPD) as a Policy Enforcement Point. A feature of the Oracle database, VPD has the ability to enforce its own policies to apply application context for row- or column-level security, and can also provide the platform for OES to examine result sets.

Sharepoint

Imagine if you had a flying machine. You’re a computer geek, right? So what if the propeller on your hat actually worked? You could pop to the store and back in a jiffy. You could defeat traffic. You could fix your roof without risking your neck on a ladder.

Now imagine you lend your propeller hat to your ten-year-old. He could get himself to piano lessons. He could escape bullies. He could get home on time from little Billy’s house. And before you know it, he’d be dropping rocks on other kids, ringing doorbells and flying away, and swooping in on little girls to pull their pigtails.

Useful tool, but almost too useful.

So now imagine having a product for creating web sites that’s so easy to use that you can create all the pages you ever need, and so can your users, and before you know it, you’ve got more sites than you’ve got people. Well, here it is! It’s called Sharepoint.

A few years back, the portal market was on life support, and companies that had been marketing their “portal servers” started calling themselves app servers, personalization servers, or anything other than a portal. Now that market’s doing well again, and Sharepoint’s a big part of that. But its ease of use also lets it get out of hand. The critical mass that Sharepoint has achieved as an all-purpose collaboration and portal tool is just about equal to the mass it has acquired as an out-of-control site generator, to the point where it rivals its creator’s LDAP clone, Active Directory, for ease of use that’s turned into leap of pages. Sharepoint allows for the administration of security policies, roles, and groups to migrate into the hands of the line-of-business owners who can too easily create sites and subsites, and out of the reach of security admins.

Fine-grained access control, based on attributes and memberships, can provide the solution to not only who can create web parts but who can see them. Oracle Entitlements Server ships with a Policy Enforcement Point (PEP) specifically built for Microsoft Sharepoint Server 2007, to provide fine-grained Microsoft Office Sharepoint Server (MOSS) protection. A single security module may support multiple MOSS servers.

OES can perform resource discovery on a Sharepoint server, and then import those resources into its inventory. There a policy can be constructed at a point in the resource tree that can be inherited by the child objects, such as web parts inheriting from a parent. Protection can be easily extended to:

Sites

Pages

Web parts

List items

Documents

Microsoft Office Active Server Page Framework (ASPX)

This control can be so granular that you can tag sensitive content, and even “turn off” unauthorized parts, on a page that is otherwise viewable.

Standard MOSS security involves the use of static groups, with one group for every page or site. Inheritance becomes a bad idea, since it’s an all-or-nothing access on down the chain. With OES, you can tie fine-grained access control to dynamic groups, and assign access via attributes, roles, or hierarchy. The use of externally administered dynamic groups and attributes for access decisions, instead of just static groups, provides multiple benefits. First, it’s a far more flexible approach than just “you’re in or you’re not,” and the decision making itself becomes more dynamic, since it can be predicated on values that may have changed. If your account balance has dropped below a certain level, you’re out. If your mileage balance has exceeded the “Average Flyer” level, you’re in.

This means you can mitigate access to a subpage level. Web parts, list items, document libraries can all be subdivided by policy. You and I can both visit a page, but I can’t touch the admin links. Maybe I can’t even see them.

By not having to rely on MOSS-specific groups, you are free to make policy decisions based on groups and attributes that may be used across platforms or apps. It’s one of the benefits of RBAC in itself: I assign you a role, and that by itself grants you access to all those resources to which you need access in order to do your job. The way Sharepoint is deployed in the enterprise, it’s rarely the only thing you’ll be touching. Remember the framework? Sharepoint is just one of the resources riding on that train, and doesn’t have to be its own beast, separate from the rest.

OES not only protects the content, but also the administrative functions. Therefore it is managing who can create pages and publish content, and then who can access it. Remember, Sharepoint’s strength in ease of use is also its weakness in allowing runaway sites. So by plugging in an authorization model, you’re controlling who can create what, and who can see what.

Another reason to plug in an externalized access control mechanism into Sharepoint is compliance. In addition to enforcing SoD policies that Sharepoint itself cannot provide out of the box, the presence of a plug-in that mitigates requests also allows for usage reporting. Otherwise, you might be relegated to Internet Information Server (IIS) logs, which is even worse when you’re talking about IIS farms, and having to collate reports from multiple logs. The centralized security provides you with data on both requests and responses, one-stop shopping for reports on all Sharepoint instances.

By employing this model, you are keeping a leash on both uncontrolled growth and uncontrolled access, and allowing Sharepoint to be a useful platform without making it a vulnerable spot in your enterprise, or a compliance nightmare.

Federation

We’ll take just a moment to explain federation, since too often it’s not fully understood, and is sometimes misinterpreted as simply multidomain SSO. You enter a building, you check in with the security guard, and he checks out your ID, and off to the elevator you go. You’ve signed in, and that’s good enough to get you into certain rooms with certain assets. But now you want to go to another building, owned by another company with whom your organization has an arrangement. Either your security guard gives you a badge that’s good enough for the guard at the other building to let you in, or else a piece of paper explaining who you are, and when you show up, the second security guard calls your company’s security guard to verify your identity, and then off to the elevator you go. You’ve been federated.

Federation is moving from one domain to another, without having to reauthenticate. Wow, that sounds like cross-domain single sign-on. Why can’t I just do that? Because in regular cross-domain SSO, you own both domains, allowing you to implement cookie providers on your web servers. In the case of federation, you start in one of your own domains, but eventually navigate to another domain that you don’t own.

What’s the business case for that? Usually when you’re branching into other apps hosted by sites that provide services for your users.

Click a link on your company portal that lets you check your outsourced benefits, medical insurance, 401K, and so on.

Allow your suppliers to check your inventory, to facilitate bidding on upcoming requirements.

At my employer, I can shop for company-approved peripherals, at company-negotiated prices, get approval for a purchase, pop over to the vendor sites, order the goods, then pop right back and authorize payment.

Before the establishing of standards for federation, and even before it was commonly referred to as federation, there were other ways of accomplishing the same end, although they were somewhat limited. One mechanism that seemed to dry up overnight was affiliation. Much like a web server plug-in methodology, affiliation relies on installing an affiliate plug-in or agent on a trusted service provider’s web server. By means of encrypted tunneling, the affiliated plug-in communicates with the IdP’s identity framework. It wasn’t a bad architecture, but had a major hurdle: No matter how much I trust you, I don’t want to install your plug-in on my web server. Even if it’s nearly impossible, I fear that somebody compromising the IdP’s administrative server would have an open door, through the tunnel to the affiliated plug-in, into my web server. This architecture has always been a tough sell because of the need for trust.

So federation is all about trust. This is not a technical issue; it’s a business one. You must decide that a federation partner can be trusted; that is, if they send you an assertion for a user, you can trust that they have properly authenticated that user. But the difference between affiliation and federation is that both parties are hosting their own platform for dealing with it, not each other’s.

Federation between parties requires two things: trust, and speaking the same language. In a federated association, the user authenticates at one site, the Identity Provider (IdP), which is most likely home base. She wishes to visit a second site, the Service Provider (SP), which most likely partners with home base. The IdP provides an assertion, a package of authentication and authorization data, stating that the user is worthy of visiting the SP, and by the way, here’s the stuff she should be able to access while she’s there. After all, the domain cookie from the home base domain won’t suffice.

Let’s boil down the simplest use case. The user authenticates at her home domain. She decides to head to the second domain. The IdP generates a ticket for her to be used at the SP. The SP validates the ticket, and provides her with a session cookie for the SP’s domain.

The IdP and the SP must have an established trust, to recognize and digest each other’s tickets, which are called assertions. They assert your worthiness to enter the second domain. The IdP and SP need to share a protocol for these assertions. One of the most common protocols is Security Assertion Markup Language (SAML), which itself is a form of framework, for exchanging security data so that one site or process can interact with another. It is XML-based, and facilitates both authentication and authorization. For example, a user has an identity that is established in a particular domain, and she wishes to do business in another domain. SAML is the basis for her ticket from the first domain to the second. The primary piece of information is the user’s name identifier, which is often her e-mail address, since it’s a unique ID, and clearly states the user’s domain of origin.

One of the great benefits of federation is not having to maintain the identities of users coming from a trusted partner site. They maintain the identities for you, and vouch for them when they come for a visit. There is also the liability that can come with storing that identity data.

There are a variety of standards (surprise, surprise) for federation. We have the OASIS and Liberty Alliance groups, which are all about open standards; WS-Security, driven by Microsoft, VeriSign, and IBM, and which is still a standard per se, but perhaps a little more platform-bound; and Shibboleth, which is another academic standard (that is, higher education). All are constantly evolving. In the past year, I sat in the audience of an hour-long, hundred-slide presentation on the differences between SAML 1.0 and 2.0, and it barely scratched the surface. They support different attributes and identifiers. This topic would be a book unto itself—in fact, it’s already several—so grab one of those books, find a spot on the beach, and go nuts.

NOTE

Shibboleth is an authentication and authorization infrastructure designed to grant students access to educational resources. While authentication is still a function of the student’s home base (that is, school), authorization is provided by the service provider. Access is typically based on user attributes and/or role, without the need for personal data, which protects student privacy. Throughout the process, users and/or their respective institutions may need to provide additional info for authorization. This is actually an elegant model, and barely adopted.

So federation is authentication and assertions. If you’re only the service provider, you may only need to digest assertions. And by the way, there are lots of different kinds of tokens, including simple identity, certificates, SAML assertions, biometrics, Kerberos, and so on. It really depends on the requirements of the target system. The essence of it is that federation requires running an assertion engine.

Federation is one of those many things that everybody talks about, but not nearly as many people actually deploy. I’ve done many presentations and RFPs regarding federation, and only a modest percentage deploy it. If you only need cross-domain SSO within your own enterprise, it may be more infrastructure than you need. If you are federating to another site merely for the sake of SSO, and will bring no information home with you, you may consider whether it’s worth it to generate assertions simply to save another login.

But in the increasingly cross-functional, cross-pollinating corporate environment we live in, true federation is becoming not only useful, but utterly compelling. Many of the larger manufacturing customers I have, for example, to whom I was invited separately, now do business with one another, embedding and/or selling each other’s products and services. They trade information on suppliers, inventories, manufacturing schedules, and customers. This is where federation allows for timely and secure interaction without that unfortunate dinosaur of data exchange, the flat file.

Without the trusted security of federation, many organizations are failing to take advantage of Software as a Service (SaaS). Having your users authenticate to an external site is not the same as seamlessly interacting with that site from the familiarity of the home portal. Besides that, it means a proliferation of identities. Federation allows users to make use of partner resources based on their own identity, which is additionally a benefit to the service provider who can not only recognize a trusted partner’s user base, but also save themselves the maintenance of another set of user accounts. However, in some cases it may be desirable, for enhanced security, to maintain those identities. The approach you take depends on how much trust you have. We’ll cover both angles in a bit.

Oracle’s Federation Solution

To address the need for federation, not as a point solution but as part of an overall IAM framework, Oracle provides OIF, or Oracle Identity Federation. It is a highly scalable, easily deployable, standards-based federation platform. By integrating with a wide variety of applications, directories, and data stores, OIF preserves existing investments in corporate assets.

A common hurdle in federation is the time required to deploy new partners in the framework. With OIF, partner sites can be brought online and integrated with your processes quickly, making use of any standard federation protocol:

SAML 1.0, 1.1, and 2.0

WS-Federation

Liberty Alliance ID-FF

You still manage identities centrally and securely. As a federation consumer, you can also integrate with external authentication and authorization schemes. OIF publishes a toolkit for integrating with any IAM platform your partners may deploy. It allows you to act as the ID, performing authentication and generating assertions, which can be digitally signed and encrypted. You can also act as the SP, validating and authenticating assertions from trusted partners and authenticating the federated users locally. OIF also supports X.509 certificates for digital signatures and encryption. Through the console, administrators can manage certificate authorities and certificate revocation lists.

Let’s go back to the concept of the framework. Oracle Identity Federation is managed via Oracle Enterprise Manager (OEM), which we’ll talk about in more detail under postimplementation concepts in Chapter 19. In summary, OEM provides the ability to monitor the performance of the components of a solution, including the non-Oracle components such as directories and application servers. OIF comes bundled with OEM. By providing enterprise-level operational management tools, OIF allows administrators to

Ensure the health and performance of servers and adapters

Monitor from a single dashboard the complete architecture of all Oracle and non-Oracle components in the federation platform

Generate alerts

Trace transaction activity across components

Use BI Publisher, Oracle’s business intelligence tool, for generating reports on all user and administrative activity

OIF also comes bundled with WebLogic Server, which provides a command line scripting tool for additional customizations.

Oracle is also integrating into OIF the Fedlet, a lightweight extension to federation inherited from Sun (although not full-blown federation), which allows a Service Provider (SP) to quickly federate with an Identity Provider (IdP), for providing single sign-on and retrieving attributes from the IdP. Oracle has also inherited STS (Security Token Service), which establishes trust between business partners online, by way of web services. STS supports exchange and validation of security tokens, and is integrated with OAM. It’s a form of federation without real federation. One of the key hurdles to establishing a federation partnership is a lack of federation capability by one of the parties. If you’re not speaking the same language, the exchange of data is a moot point. So having a lightweight option opens the possibilities.

Federation Types

Even in a trusted relationship, there may still be limitations. Certainly you don’t share all information, even with trusted partners. You’re not trusting them with your life, only with your common transactions.

As stated earlier, federation can be looked at as either authentication or authorization. I chose authorization because the first type of federation, transient federation, does not require dual identities. The user is authenticated only in his originating domain, and only his session is communicated to the trusted domain. A large part of the trust is the presumption that the sender is enforcing all necessary access controls, and therefore Oracle Access Manager is often used as the authority for authentication and authorization in conjunction with OIF.

For those partners for whom transient federation is too much risk, there is the more secure, and more complex, solution of account mapping. In this configuration, users have identities residing with both partners, which must have some type of commonality, such as a UID. An assertion must contain this accepted identifier and validate it locally before granting access. This architecture provides the SP a greater degree of control. Mapped accounts can also be managed through the OIF console.

Additionally, account linking provides the ability to update the target directory in the event account mapping does not readily find a common user this time around, but wants to find them next time.

If a partner doesn’t wish to maintain another partner’s identities, they can employ attribute federation, in which the assertion provides roles, attributes, privileges, or other access control elements that determine not who the user is, but what they can do. Naturally, this requires that the trusted partners agree on what these roles are in advance, and the necessary attributes to assign access during a session.

Database Security

I want to stop briefly on a subject that we’ll cover a bit more under compliance, and that is database security. To reiterate an earlier point, databases are often treated separately from other corporate assets. They are often considered part of the infrastructure, with insufficient thought as to how the databases themselves are provisioned and governed. For this reason, Oracle provides a number of solutions. One of these falls at least partially under the heading of authorization, and that is Oracle DataBase Vault (ODV).

DataBase Vault provides the ability to create realms of protection around application data without having to modify application code. Privileged users can be limited to essential functions, and be kept out of application-relevant data. Security realms act as database firewalls, controlling the areas that these privileged users can work in. It can also enforce Segregation of Duties, ensuring that policy of least privilege I keep mentioning. With regard to authorization, ODV can make use of mitigating factors such as authentication method and originating IP address to determine access to trusted realms. Policies can be applied to database commands for more granular control. Data cannot be read, moved, or modified except by authorized users.

As with OIF, DataBase Vault can be managed via Oracle Enterprise Manager. Full reporting is also available, to track administrative and user activity.

Specific integrations have been built and certified for a number of business applications, including Oracle eBusiness Suite, PeopleSoft, SAP, Siebel, and JD Edwards. This means that ODV understands realms of protection that are application-aware, with consideration for separation of duties within those application functions.

In the last few chapters, we’ve discussed how to identify, onboard, and secure users, then authenticate and authorize them to use corporate assets. Throughout, we’ve included the means to secure these functions, for safety and compliance. Next, we will discuss additional compliance considerations, including industry-standard requirements. When it comes to regulatory mandates, you can’t just worry about yourself; you’re required to worry about everybody else as well.