Friday Nov 13, 2009

The JSON Schema Behind the Entitlements Service

What better day than Friday the 13th to write about the JavaScript Object Notation (JSON) schema used by the Entitlements Service to write the privilege objects returned by Those Darlin'OpenSSO REST Policy Evaluation Interfaces. JSON is relatively easy to read and understand. According to Introducing JSON, it is easy for machines to parse and generate...and is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. (Check out the link for more information.)

An Entitlements Service privilege object has the following attributes:

  • description is a descriptive string.
  • entitlement is made up of:
    • name (any arbitrary unique String)
    • application name
    • set of action values (String to boolean)
    • list of resource names
    • a list of exclusive resource names
  • subjects can include one or more entitlement subjects; in that case, logical subjects such as OrSubject and AndSubject are used. Please refer to sub section, Sub ject JSON Representation for schema for the support sub jects.
  • conditions can include one or more conditions; in that case, logical conditions such as OrCondition and AndCondition are used. Please refer to sub section, Condition JSON Representation for schema for the support conditions.
  • attributes may include user and static attributes.

There's more information to come but, in the meantime, here's another Jason - the Friday the 13th kind - in He's Back - The Man Behind the Mask. I don't know what's scarier the video (filled somewhat with oozing Karo Syrup) or this 80s-induced track sung by Alice Cooper. Mwahahahahahahahaha!!!!

Tuesday Nov 10, 2009

Those Darlin' OpenSSO REST Policy Evaluation Interfaces

Piggybacking on the information in The OpenSSO REST Interfaces in Black / White, OpenSSO Express 9 will mark the release of the RESTful interfaces for policy evaluation. All of them support both HTTP GET and POST actions, and some of them return JavaScript Object Notation (JSON) objects. The format of the OpenSSO REST URL is:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/OpenSSO-REST-interface?parameter1=value1&parameter2=value2&parameterN=valueN

NOTE: If the value of the parameters (value1, value2, ..., valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

The following sections contain information on invoking the available OpenSSO REST policy evaluation interfaces.

Evaluating a Decision for One Resource

The decision RESTful policy evaluation interface returns a plain text string of deny or allow in regards to a request for access. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • action defines the action to be evaluated.
  • resource defines the resource to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/decision?action=GET&resource=http://www.example.com/index.html&application=iPlanetAMWebAgentService&subject=uid=demo,ou=user,dc=opensso,dc=java,dc=net&env=requestTime%3D1248994000000

Evaluating a More Specific Decision for One Resource

The entitlement RESTful policy evaluation interface returns a list of JSONEntitlement objects in regards to a request for access to a resource. Although similar to the decision interface, it does allow more information to be returned as a JSON privilege object. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resource defines the resource to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/entitlement?resource=http://www.example.com&application=iPlanetAMWebAgentService&subject=uid%3Ddemo,ou%3Duser,dc%3Dopensso,dc%3Djava,dc%3Dnet

The following result signifies that the evaluation has approved the request for access. But, demo does not have access permission to http://www.example.com because the IP address does not fall within the range of 192.122.18.1 and 192.122.18.254.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{
               "com.sun.identity.entitlement.IPCondition": "[
                    \\"requestIp=192.122.18.1-192.122.18.254\\"
               ]"
          },
          "resourceName":"http://www.example.com"
       }
   }
}

Evaluating a Decision for Multiple Resources

The decisions RESTful policy evaluation interface returns a list in the form of a JSONEntitlements object in regards to a request for access to a set of resources. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resources defines the set of resources to be evaluated. More than one resources parameter may be added to the URL.
  • application defines the (application or application type). This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/decision?resources=http%3A//www.example.com/index.html&resources=http%3A//www.example2.com/index.html&application=iPlanetAMWebAgentService&subject=uid%3Ddemo,ou%3Duser,dc%3Dopensso,dc%3Djava,dc%3Dnet

The following result signifies that the evaluation has approved the request for access. Additionally, demo (the OpenSSO demo user) has POST and GET permission for http://www.example.com and GET permission for http://www.example2.com.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
             "POST":true,
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com"
       }
       {
          "actionsValues":{
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example2.com"
       }
       ]
   }
}

Evaluating a Decision for A Root and Sub Tree Resources

The entitlements RESTful policy evaluation interface returns a list in the form of a JSONEntitlements object in regards to a request for access to root resource and its (multiple) sub resources. For example, given the root resource of http://www.example.com, results for all sub resources (including http://www.example.com/hr/\*, http://www.example.com/eng/\* and http://www.example.com/sales/\*) will be returned. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resource defines the root of the set of resources to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/entitlement?resources=http://www.example.com&application=iPlanetAMWebAgentService&subject=uid=demo,ou=user,dc=opensso,dc=java,dc=net&env=requestTime%3D1248994000000

The following result signifies that the evaluation has approved the request for access. But, demo (the OpenSSO demo user) has POST and GET permission only for http://www.example.com/hr/\* and http://www.example.com/engr/\*.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com"
       }
       {
          "actionsValues":{
             "POST":true
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com/hr/\*"
       }
       {
          "actionsValues":{
             "POST":true
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com/engr/\*"
       }
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{
               "com.sun.identity.entitlement.IPCondition": "[
                    \\"requestIp=192.122.18.1-192.122.18.254\\"
               ]"
          },
          "resourceName":"http://www.example.com/sales/\*"
       }
   }
}

Now enjoy the musical and illustrative (?) accomplishments of Those Darlins with Red Light Love. It's dope. And that's a good thing!

Monday Aug 24, 2009

Breakaway from the Policy Service with OpenSSO Entitlements

Appropos to Dennis's announcement of the Entitlements Service source code being moved into the OpenSSO workspace, here's some information about the developing OpenSSO Entitlements Service.

The Entitlements Service is an authorization and policy component developed for inclusion in the soon-to-be-released OpenSSO Express 8. The user interface provides an easy-to-follow process to define rules for controlling access to applications and web resources. You can create fine-grained policies, and referrals (to assign policy creation based on an OpenSSO realm hierarchy), using these work flows.

The Entitlements Service is being developed in tandem with a new beta OpenSSO administration console. The OpenSSO Enterprise Policy Service, used for more coarse-grained policy implementation, is still available using the standard OpenSSO administration console. See The New OpenSSO Console Rip-Off.

From a high level a service used to create and manage access to web resources consists of the following:
  • A policy administration point (PAP) that comprises the interfaces used to create, read, update and delete the policies.
  • A policy evaluation engine or policy decision point (PDP) that, acting as a policy information point (PIP), is used to query permissions and privileges in order to obtain policy decisions. It gets identity attributes and applicable policies, evaluates the information, and returns the latter with a policy decision to be used for enforcement.
  • A policy enforcement point (PEP) is an agent, installed on the same machine as the resource, that protects it from unauthorized access.
  • A user data store for storing and obtaining identity data.
  • A policy data store for storing policies and the service's configuration attributes, and obtaining said data. (OpenSSO embeds OpenDS for its configuration data store. This configuration data store is used to store Entitlements Service data.)

Different types of resources can be protected by the Entitlements Service. By selecting a general application and adding a more specific resource with applicable subjects and conditions, a policy can be created to define authorization using the new beta console administration interface. An application (term as used in the Entitlements Service) consolidates meta data for generic resource types that share a common set of actions. The format of a resource's definition, supported actions, conditions and subjects, decision combining algorithms (to resolve conflicting policy results) and other data can be defined as a schema for an application. Examples of applications in the Entitlements Service could be calendars, web resources, or user profiles. The following applications are added by default when deploying opensso.war.
  • Web Agent defines actions that can be used to create and manage policies that protect HTTP and HTTPS URLs through the use of a policy agent. This is the most common application use case with the following actions.
    • GET has these operations.
      • Allow: Enables access to the resource defined in the Rule.
      • Deny: Denies access to the resource defined in the Rule.
    • POST has these operations.
      • Allow: Enables access to the resource defined in the Rule.
      • Deny: Denies access to the resource defined in the Rule.
  • Liberty Personal Profile allows administrators to create and manage policies corresponding to actions that can be performed on identity attributes in a personal profile service defined by the Liberty Alliance Project specifications; for example, the OpenSSO implementation of the Liberty Personal Profile Service.
    • MODIFY has these operations.
      • Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource in order to modify it.
      • Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to modify a value on a resource.
      • Allow: Enables access to the resource defined in the Rule in order to modify an attribute value.
      • Deny: Denies access to the resource defined in the Rule therefore modification is disallowed.
    • QUERY has these operations.
      • Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource.
      • Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to query a resource.
      • Allow: Enables access to the resource defined in the Rule in order to query the resource.
      • Deny: Denies access to the resource defined in the Rule therefore the query is disallowed.
  • Discovery Service allows administrators to create and manage policies corresponding to actions that can dynamically determine a web services provider (WSP) registered for a particular principal.
    • LOOKUP: Allow or Deny access to search the discovery service.
    • UPDATE: Allow or Deny access to modify data in the discovery service.
A resource is an object on which you can perform an operation or an action. The policy is specifically configured to protect this object. A resource is a string; it could be a URL, a web service, a bank account, or graphical user interface controls (buttons, text fields and the like). Examples could be MyCalendar or other portal type services (located with URLs), a bank account, or a Submit button on a text form.

More information on the Entitlements Service will be forthcoming; these definitions should help you get started, in a small way, by following the inline help developed for the Entitlements Service GUI. But first - enjoy Tracey Ullman singing Breakaway into her hairbrush.

Monday Jan 12, 2009

Give Him OpenSSO Resource-based Authentication

Policy agents deployed to web containers and web proxy servers protect content from unauthorized intrusions. Access to this content (services, for example) are controlled through policies configured with OpenSSO. Here is a description of the interactions that occur when a policy agent interacts with OpenSSO.
  1. A policy agent intercepts the user's request and validates any authentication credentials contained within it. If the existing authentication level is insufficient, the OpenSSO Authentication Service will present a login page for an authentication upgrade. The login page prompts the user for the credentials appropriate to the configured module.
  2. The Authentication Service verifies that the user credentials are valid. For example, the LDAP authentication module verifies that the user name and password are the same as those stored in the LDAP identity data store. If other authentication modules are passed to the user (such as RADIUS or Certificate), the credentials are verified with the appropriately configured identity data store.
  3. Assuming the user's credentials are properly authenticated, the policy agent examines the policies assigned to the user.
  4. Based on the aggregate of the user's configured policies, the individual is either allowed or denied access to the resource.

NOTE: In this scenario, if the user attempts access to a web resource without authentication credentials, the agent redirects the user to the login page of the default authentication module. (Even if the resource is protected by a different authentication module, the user must first authenticate using the default authentication module.)

Because some customers require a scenario in which the user authenticates against a particular module based on the resource being accessed, the Gateway servlet provides resource-based authentication; there is no need for the user to authenticate to the default authentication module to access the protected web resource. When using the Gateway servlet:
  • A web resource can not be defined in more than one policy. For example, if abc.html is defined in a policy definition as requiring LDAP authentication, abc.html can not be defined in a second policy definition as requiring Certificate authentication.
  • You can use the level and scheme conditions only when defining policies that the servlet will examine.
Additionally, the Gateway servlet does not work across internet domains. Use the following list to configure your deployment to use the Gateway Servlet.
  1. Configuring the Web Container
  2. Configuring OpenSSO
  3. Configuring the Policy Agent
  4. Testing the Servlet
Configuring the Web Container

Generically speaking, you must ensure the following configurations on your web container. Check your container's documentation for information on how to do them.
  1. Check that the following certificates are installed:

    • A certificate for the server (Server-Cert).
    • A certificate for the trusted Certificate Authority.
  2. Add a listen socket for simple Secure Sockets Layer (SSL) and one for SSL client authentication.
  3. Ensure that the listener port configuration requires SSL for client authentication.
Configuring OpenSSO

  1. Log in to the OpenSSO console as the administrator.
  2. Click the Configuration tab and the Authentication tab under it.
  3. Click the Certificate Service Name link.
  4. Enable Match Certificate in LDAP by checking the box.
  5. Select Subject UID as the value for Certificate Field Used to Access User Profile.
  6. Enter 54430 as a value for SSL Port Number.
    This port number must match the port number used for the web container's SSL client authentication listener port in the previous procedure.
  7. Type 2 as the value for the Authentication Level attribute.
    The value used must be greater that the level defined for LDAP authentication.
  8. Click Save.
  9. Click Back to Service Configuration.
  10. Under the appropriate realm, add policies for three URL resources:

    1. policy1 has a condition of LDAP authentication only for http://agent-machine.domain/banner.html.
    2. policy2 has a condition of Cert authentication only for http://agent-machine.domain/banner2.html.
    3. policy3 has a condition of LDAP authentication and a level of Certificate authentication for http://agent-machine.domain/banner3.html.
See the OpenSSO Enterprise 8.0 Administration Guide for the official documentation on configuring OpenSSO Enterprise 8.0 for resource-based authentication.

Configuring the Policy Agent

  1. Go to the installation directory for the agent protecting the resource on the web container host machine. For example, on Application Server, change to AppSvr-Directory/agents/j2ee_agents/appserver_v9_agent/Agent_001/config/.
  2. Change the value for com.sun.am.policy.am.loginURL from http://machine-name.domain:port/opensso/UI/Login to http://machine-name.domain:port/opensso/gateway in OpenSSOAgentBootstrap.properties. It is the only change to the policy agent configuration.
Testing the Servlet

After these configurations, the test results are:

  • Access to resource A is permitted only after successful LDAP authentication.
  • Access to resource B is permitted only after successful Certificate-based authentication.
  • Access to resource C is permitted only after both successful LDAP and Certificate-based authentication.

Now that you've configured and tested resource-based authentication, the Shangri-Las are gonna give you a great big kiss with Give Him a Great Big Kiss. I was reminded of this song when it was used in a movie I saw this weekend called Stonewall, an account of the Stonewall riots of 1969. Worth checking out!

Thursday Jul 17, 2008

Enabling PUT and DELETE Actions in OpenSSO Policy Definitions for Web URLs

Policy rules in OpenSSO allow control over GET and POST actions but, by default, do not list PUT and DELETE. Following are two procedures for adding the latter actions. When Deploying a New Instance of OpenSSO
  1. Explode opensso.war.
  2. cd WEB-INF/classes
  3. Create AttributeSchema elements for PUT and DELETE in amWebAgent.xml using the already existing AttributeSchema for GET and POST as the prototype.
  4. Add i18n keys and values to amWebAgent.properties for the elements created in the previous step.
  5. Regenerate the WAR.
  6. Deploy the WAR.

When Modifying an Existing Instance of OpenSSO
  1. Explode opensso.war.
  2. cd WEB-INF/classes
  3. Create AttributeSchema elements for PUT and DELETE in amWebAgent.xml using the already existing AttributeSchema for GET and POST as the prototype.
  4. Copy amWebAgent.xml outside the exploded WAR directory.
  5. Add i18n keys and values to amWebAgent.properties for the elements created in the previous step.
  6. Regenerate the WAR.
  7. Redeploy the WAR.
  8. Set up the famadm command line interface.

    • Download and unzip opensso.zip.
    • Change to the opensso/tools directory and unzip famAdminTools.zip.
    • Follow the instructions in README.setup.

  9. Run the following command:

    famadm delete-svc -s iplanetamwebagentservice
  10. Run the following command:

    famadm create-svc --xmlfile /path/amWebAgent.xml
And now enjoy Eddie Money and Ronnie Spector singing Take Me Home Tonight.

Thursday Apr 10, 2008

The Policy Condition Timeout Value Makes Time for Spike Jones

The Timeout Value attribute of the Policy condition Authentication by Module Instance defines when the application (defined as the value of the Application Name attribute of the Policy condition Authentication by Module Instance) should force re-authentication.

CAUTION : The application name (app_name in session below) is a grouping of resources being protected. For example, all resources that constitute the paycheck application can be defined as paycheck. So, if the same app_name (in this case, paycheck) is used in two different policies with different Timeout Value values, the result is randomly picked up.

An authenticated user can lose access to a protected resource after a defined amount of time has passed (from the time of authentication). If the user attempts access after the time is up, the policy agent will force authentication again using the scheme configured in the Authentication by Module Instance condition. After successful authentication, the user will again be allowed access to the resource. Re-authentication will be required to access the protected resource, if idle, regardless of the session time limits. (If the Timeout Value is longer than the maximum session time, the user will not be affected by it but, if the session's idle timeout is reached, the session will timeout.)

For example, assume Application A and Application B are configured for single sign-on. Additionally:

  • Application A has a Timeout Value equal to 10 minutes
  • Application B has a Timeout Value equal to 60 minutes

A user successfully logs in to Application A and receives a session token. When the same user accesses Application B, no additional authentication is needed. But, after ten minutes of idle time, Application A requires re-authentication. A use cases for this attribute might be when user jdoe logs in to a protected application configured for re-authentication after 10 minutes of idle time (from the time of authentication set in the session). jdoe leaves the public computer with out closing the browser, and user jsmith arrives ten minutes after and attempts to access the resource again. The login page is displayed and jsmith must authenticate before access is permitted.

One thing to keep in mind is that this attribute value does not depend on the session time limit. For every time authentication is forced, the moduleAuthTime property in the session token is checked against the value of the Timeout Value condition in the policy. A typical session might look like this:

<Session sid="AQIC5wM2LY4Sfcy6UFgE25jdHKzJwphzxFrvqL1suAk/8aU=@AAJTSQACMDE=#" stype="user" cid="uid=amAdmin,ou=People,O=SUN\\\\ MICROSYSTEMS INC." cdomain="o=sun microsystems inc." maxtime="120" maxidle="30" maxcaching="3" timeidle="10" timeleft="6694" state="valid">
<Property name="CharSet" value="UTF-8"></Property>
<Property name="UserId" value="amAdmin"></Property>
<Property name="successURL" value="/amserver/console"></Property>
<Property name="cookieSupport" value="true"></Property>
<Property name="am.protected.policy.AppIdleTimesoutAt.app_name" value="1172883917924"></Property>
<Property name="AuthLevel" value="0"></Property>
<Property name="SessionHandle" value="shandle:AQIC5wM2LY4SfczFsOZaE5/uQQtygnlHv1mJuFlOY3K4uUg=@AAJTSQACMDE=#"></Property>
<Property name="UserToken" value="amAdmin"></Property>
<Property name="loginURL" value="/amserver/UI/Login"></Property>
<Property name="IndexType" value="module_instance"></Property>
<Property name="Principals" value="uid=amAdmin,ou=People,O=SUN MICROSYSTEMS INC."></Property>
<Property name="moduleAuthTime" value="LDAP+2007-03-03T01:04:17Z|mem+2007-03-03T01:06:39Z"></Property>
<Property name="sun.am.UniversalIdentifier" value="id=amadmin,ou=user,o=sun microsystems inc.,amsdkdn=uid=amadmin,ou=people,o=sun microsystems inc."></Property>
<Property name="amlbcookie" value="01"></Property>
<Property name="Organization" value="o=sun microsystems inc."></Property>
<Property name="Locale" value="en_US"></Property>
<Property name="HostName" value="129.145.155.166"></Property>
<Property name="Host" value="129.145.155.166"></Property>
<Property name="UserProfile" value="Required"></Property>
<Property name="AMCtxId" value="4b21c5d982164fbe01"></Property>
<Property name="clientType" value="genericHTML"></Property>
<Property name="authInstant" value="2007-03-03T01:06:39Z"></Property>
<Property name="Principal" value="uid=amAdmin,ou=People,O=SUN MICROSYSTEMS INC."></Property>
</Session></GetSession>
The following properties in the session are relevant.
  • am.protected.policy.AppIdleTimesoutAt.app_name
  • moduleAuthTime

NOTE : The protecting policy agent should run in self policy decision cache mode and the com.sun.am.policy.am.fetch_from_root_resource property should be set to false.

I'm taking tomorrow off to spend the weekend in Yosemite. 65 years ago, Spike Jones and his City Slickers made a soundie that neatly sums up how I feel having three days off.

Thursday Mar 06, 2008

The One-Level Wildcard for Policy Logic

UPDATE-3/21/08: The one-level wildcard is currently only available to the J2EE agents - not the web agents.

After putting together the couplet entries on policy logic in OpenSSO and wildcard matches in policy agents, I received an email from Bhavna, one of Sun's Federated Access Manager engineering gurus, who wrote - and I cut and paste:

good addition. You might want to add some information on one level wild card too which, by default, is "-\*-"
unfortunately we don't have much documentation on it.

NOTE: I'm thankful for that last sentence myself.

Well here is the scoop that turns our couplet into a triplet. The one-level wildcard was introduced in Sun Java System Access Manager 7.1. The wildcard itself is -\*- and it matches only the level for which it stands without crossing delimiter boundaries. A policy can include the one-level wildcard in resource names to allow and deny access. For example, if you allow access to http://www.sun.com/b/-\*-/d in a policy definition then access to http://www.sun.com/b/c/d will be allowed but access to http://www.sun.com/b/c/e/d will be denied. -\*- would match any character but only at the defined level.

And, in honor of all the gurus at Sun, here's a music clip from a very funny and sweet movie called The Guru. It's American-financed but filmed in the Bollywood-style. (Any suggestions on some Bollywood movies I should see would be appreciated.) The song is called Chori Chori which from my perusal on the internet means "secretly".

Once you've met The Guru, love will never sound the same.

Tuesday Mar 04, 2008

Wildcard Matches in Policy Agents

A comment was left in yesterday's entry on policy logic concerning the lack of consistency in how the different policy agents treat the wildcard. Now I am not an agent expert but I did manage to gather some information for Mr. Robinson that, I hope, helps to shed some light on how the wildcard is used by agents.

The Policy Service in OpenSSO supports policy definitions using an asterisk (\*) as the wildcard. Only \* is supported as a wildcard and it can not be escaped as in \\\*.

A \* :

  • matches zero or more occurrences of any character.
  • spans across multiple levels in a URL.

The following matching rules assume (rightfully so) the wildcard character is \* and the delimiter character is /.

  1. \* matches zero or more characters, including /, in the resource name.
  2. \* matches one or more characters, including /, if the \* appears at the end of the resource name and it is immediately preceded by a /. For example, abc/\* doesn't match abc.
  3. Multiple consecutive / characters don't match with a single /. For example, abc/\*/xyz doesn't match abc/xyz.
  4. For purposes of comparison, trailing / characters will not be considered as part of the resource name. For example, abc/ or abc// will be treated the same as abc.

Here are some examples:

Pattern Matches Doesn't Match
http://xyz.sun.com:80/\* http://xyz.sun.com:80/
http://xyz.sun.com:80/index.html
http://xyz.sun.com:80/x.gif
http://abc.sun.com:80/
http://xyz.sun.com/index.html
http://xyz.sun.com:8080/index.html
http://xyz.sun.com:80/\*.html http://xyz.sun.com:80/index.html
http://xyz.sun.com:80/public/abc.html
http://xyz.sun.com:80/private/xyz.html
http://xyz.sun.com/index.html
http://xyz.sun.com:80/x.gif
http://abc.sun.com/index.html
http://xyz.sun.com:80/\*/abc http://xyz.sun.com:80/private/xyz/abc/xyz/abc
http://xyz.sun.com:80/xyz/abc
http://xyz.sun.com/abc
http://xyz.sun.com/abc.html
http://abc.sun.com:80/abc
http://xyz.sun.com:80/abc/\*/def http://xyz.sun.com:80/abc/123/def
http://xyz.sun.com:80/abc/abc/def
http://xyz.sun.com:80/abc/def/abc/def
http://xyz.sun.com:80/abc/def
http://xyz.sun.com:80/abc//def

And while we're on the subject of wild things, think of X, the seminal punk band of all time. The song in this video isn't one they wrote (for that you'd have to check out Johnny Hit and Run Paulene, Nausea or Los Angeles) but it does segue nicely. Here's X covering The Trogg's (not Tone-Loc's) Wild Thing. And that's Chuck Berry on stage at the video's end - a wild thing in his own right.

UPDATE: For more information on policy logic and wildcards see the following entries:

Policy Logic in OpenSSO

Here's some information that, thanks to a comment from a member of the OpenSSO community, I found missing from our doc set. We wrote a great deal about policy but not a heck of a lot about policy logic.

NOTE: If you'd like an overview of policy and authorization take a look at the Authorization and Policy Service chapter in the Sun Java System Access Manager 7.1 Technical overview or the OpenSSO Policy Service Architecture document. I'll wait.

Done? OK. Now that you know everything there is to know about policy, here is the last piece. All of the following should be satisfied for a policy to be applicable to a request.

  1. The Resource Name defined in a policy's Rules should match that of the protected, requested resource. The match can be an exact literal match or one due to the presence of wild cards. Currently, policy agents only support http:// and https:// URLs as a Resource Name; they do not support IP addresses in place of the host name. Wild cards are supported as a substitution for a protocol, a host name, a port number, or a resource - as in:

    http\*://\*:\*/\*.html
  2. The requesting user should satisfy at least one of the Subject(s) defined by the policy. For example, if the Subject type is defined as Access Manager Identity Subject, the requesting user should be a member of the role selected in the policy.
  3. At least one Condition in EACH selected Condition Type defined in a policy should be satisfied by the requesting user, resource and/or environment parameters. For example, if the policy is defined with two Time conditions and two IP Address/DNS Name conditions, the request should satisfy at least one Time condition and at least one IP Address/DNS Name condition.

And sometimes policies collide; when this happens, the following rules take effect:
  1. When multiple policies are applicable to a particular resource, the order in which the policies are evaluated is not deterministic.
  2. If a policy decision for a requested action is boolean, a value of false overrides one of true. For example, when deciding authorization for a web URL, deny overrides allow.
  3. If a policy decision for a requested action is boolean and the request is determined to be false based on policies evaluated thus far, no further policies will be evaluated for the requested action. This behavior can be changed by toggling the Continue Evaluation On Deny Decision attribute in the Policy Configuration Service.

So, in conclusion, sometimes musical styles collide also. When this happens there are no rules. You might get Sammy Davis, Jr. (smokin' a ciggy butt) and Cass Elliot singing their Las Vegas-style version of the Peter, Paul and Mary classic, I Dig Rock and Roll Music.

Or you get Mary dancing like she's in a mosh pit to an acoustic version of the same song.

UPDATE: For more information on policy logic and wildcards see the following entries:

Wednesday Dec 12, 2007

User and Policy Samples: OpenSSO Client SDK

Now that I've gotten through the installation of the OpenSSO Client SDK sample WAR and it's Service Configuration Servlet sample, let's take a look at other Client SDK samples. The next one on the Client SDK - Samples list is the User Profile (Attributes) Sample Servlet.

The UserProfileServlet.java sample code retrieves and displays the profile that corresponds to the user ID entered in the Username text box. I created a user profile aaaa, entered the ID and password in the text fields and, voila, straight forward and it worked.

Note the email address, given name and other information retreived.

The Policy Evaluator Client Sample Servlet retrieves from the Policy Service a policy decision that would be passed to a web agent for enforcement. I created a policy using the OpenSSO server for the resource http://www.sun.com:80 with a GET allow and POST deny rule for all authenticated users on Fridays. PolicyClientServlet.java is the call on the client side that initiates the retrieval of the policy decision.

And while you're waiting for my follow-up entries on the SSO and command-line samples for the Client SDK, you might want to check out this video of Nellie McKay and learn how to do the dance that's sweeping the nation - come one everyone, 'do the Zombie'. It'll do you good.

About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today