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.
Comments:

I believe the one-level wildcard is currently only available to the j2ee agents and not the URL agents.

Posted by Christopher Nebergall on March 06, 2008 at 02:56 AM PST #

You are correct, Christopher. Web agents still don't support this.

Posted by DocTeger on March 17, 2008 at 12:16 AM PDT #

Can you update your post to include that info? Its probably been over a year since this feature of single level wildcards was added to J2ee agents, so the discrepancy has been there for a while.

I think one of the big wholes in am documentation is that along with info about a feature, there isn't a list of limitations or restrictions about where it will or will not work. Because when I read documentation about a feature, the question I'm really asking myself is "is this feature useful to ME in my deployment?" and having to dig through lots of documentation or do my own tests takes a lot of time.

Posted by Christopher Nebergall on March 21, 2008 at 04:13 AM PDT #

Done, Christopher. I've also passed your comment on the AM docs to the rest of the staff. We often have to ppppuuuulllllll information from those who know and it ain't easy but remembering to ask one question, "Are there limitations or restrictions to this feature?" is a good place to start. Thanks.

Posted by DocTeger on March 21, 2008 at 05:30 AM PDT #

Thanks for the quick response.

Perhaps it would make things easier if your code checkin requirements where updated so that it was required for developers to create their follow up cases in opensso bug tracker before they can check in code for the new feature at all.

https://opensso.dev.java.net/public/about/faqcenter/faqgetstart.html#patch

Or even if they don't intend to fix the limitation they could still be required to document it in the case.

Posted by Christopher Nebergall on March 21, 2008 at 05:52 AM PDT #

I don't know what you mean by 'follow up cases', Christopher.

Posted by DocTeger on March 21, 2008 at 06:22 AM PDT #

>>I don't know what you mean by 'follow up cases', Christopher.

Perhaps I should have called them "follow up issues" or "follow on issues" in the issue tracker rather than cases. For example, assume the single level wildcard Enhancement was issue 100 in the bug tracker and a developer implemented a patch for for J2ee agent support only. The code reviewers wouldn't let them check in the code until they filed a new issue for URL Agent support for Single Level wildcard which would be issue 101. Issue 101 is a "follow on issue" to Issue 100 because its required to fully (or ubiquitously) implement the feature.

Posted by Christopher Nebergall on March 21, 2008 at 06:59 AM PDT #

Ahhhh, I see. But that is a whole can of worms that I, as a writer, am not privvy too. I don't know how the implementation of this particular feature began. Maybe it came from a customer or marketing rather than an Enhancement Issue. In which case it might have started out as a feature only for J2EE agents. Of course, the developer could than file a bug against the feature but if they are given a job to do for J2EE agents then there really is no bug from their perspective. These are good ideas though, Christopher, and I will bring them up in our engineering meeting to see what can be done.

Posted by DocTeger on March 21, 2008 at 07:17 AM PDT #

Post a Comment:
Comments are closed for this entry.
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