Brian Buege

+ Follow
since Oct 16, 2002
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Brian Buege

Thanks everyone! I had a ton of fun this week.
Super questions and extremely courteous responses...
Congrats to the winners!!!
21 years ago

Originally posted by Greg Ostravich:
Welcome Brian.
This book looks great!
It looks like it has examples of all sorts of great stuff from Applets to Server-Side.
Do you speak at Java User Groups?
It looks like you could do a full talk just on J2EE security.
[ October 24, 2002: Message edited by: Greg Ostravich ]

Thanks for the nice post!
Not only could someone do a full talk just on J2EE security, they could write a whole book about it! Seriously though, there's a lot of stuff there to cover... Enough to fill a multi-day course easily.
I occasionlly speak to groups of people about security on the Java platform, but am not making the JUG circuit on a speaking tour or anything...
If you've got a specific need, shoot me a private message and we might be able to work something out.
Thanks for the post!
21 years ago

Originally posted by Kevin Gilchrist:
Hi All,
I'm trying to connect to a webite whose server certificate is signed by a CA that does not contain the basic constraint extension. Gets the following error: CA certificate does not include basic constraints extension
Anyone know of a workaround?
I've combed through the Sun forums and other places and can�t find an answer, is there a policy/property I can set to say "hey don't bother checking/looking for this certificate field"? I did see an entry on the Sun forums for changing the check in API source but I'd prefer not to have to do that as I want to dsitribute the app.

Without debugging your particular problem, I can give you a general workaround:
Write your own custom trust manager to inspect the cert. Then you can programatically decide who to trust and what criteria to use.
There's a good example of this here:
Once you've configured the proper system properties, the JSSE runtime will then use your class (instead of it's own internal one) to determine access. This will use your code and you won't have to modify the API source.
Note that this is a workaround. There may also be a much more elegant solution to the problem, but without looking at your stack traces and the cert dump I can't give you much more help.
Also, I would just verify that in fact the cert really is valid and signed by a credible CA. This could be a slight warning of something else amiss.
21 years ago

Originally posted by shai koren:
when testing a little jaas login module implementation as a stand alone program i normally pass the config file name just like any initial parameter using
with web applications, when i dont have access to the starting parameters of the server,
will it be preferd to hard code the name of the file and set it like you set any property in the system, or store the name of the file in a properties or descriptor file? I guess its a matter of trading security(exposing file name) with flexibilty(use different file), where is the line?
when running with the security manager set, is there a restriction on a code executing System.getProperty(key) to check if the config file is set? could that throw a security exception? locally i tested and its file but am not sure if the on client's environment i could query this property or set it?

The JAAS configuration was meant to apply at the VM level, and so it was assumed that it could be regulated through the use of system properties.
You are correct that if you want to get or set the parameter and there's a security manager installed (with a restrictive policy file) you're going to be in trouble.
You need to build a grant statement to grant the PropertyPermission("", "read,write") in your policy file.
Hope this helps!
21 years ago

Originally posted by G Vanin:
Brian, thank you answering me in
I have more questions there basically abt what was the evolution in security and what will be next.
It is also very important for running the code from articles on Internet, since things change, there are articles 3 years old, and no explanation abt what they were/are using. A little bit of confusion.
For ex., IBM's security suite is evaluating since April 1999. It is interesting, if I read an article from 2000 (or even 1999) how may I get that suite from 2000, etc.?
How many your books are on promotion? Whether the CD is self-sufficient for reproducing examples without referring to Internet (I use JDK1.3.1, and access Internet through library or books' CDs)

Unfortunately, some security specifications and mechanisms are changing rapidly in the J2EE arena (especially in the area of web services).
However, some of them are starting to standardize and mature - Servlet / JSP / and EJB security. This is natural given the young age of the technology.
Your best bet is to keep up with forums like this one to stay informed about what's going on. Often, I learn more from my peers who actually build this stuff every day than the "experts." In this vein, writing and running test code and apps is also helpful to get ideas about what's possible, and within that set, what's practical.
Unfortunately, the book doesn't come with a CD
We've got a companion website (see link below) where you can download the complete source code from the book (along with ant build scripts), but unfortunately it requires you to download the tools used by the app separately (and some of these are pretty huge: Tomcat, Ant, the J2EE RI, etc). Also, the sample code is built to run on JDK 1.4 and above because one of the major changes from 1.3.1 to 1.4 was the integration of many important security features into the JDK (like JAAS, JCE, and so on).
If you're really super bandwidth constrained and live within the US, send me a private message and we can work out a solution to get you the stuff you need.
Hope this helps!
21 years ago

Originally posted by Cathy Gorchkova:
Hi, Brian
What is the best solution for handling instance-level security in Entity beans? How to return to the user a subset of entity beans he can access?
I wish to avoid retreiving all the beans first and then check authorization for every entity.

This is a very good question! It's also a question that I could write at least an article on (maybe a whole chapter for a book...) So, I apologize in advance if my response isn't totally comprehensive.
Here's a quick answer:
Whenever anybody says "instance level" security my ears always perk up... I'm assuming what you mean is that you want the ability to create a constrained entity bean "view" of the data based on the identity of the caller... Kind of like setting up a view in the DB where one of the criteria was identity based... Tell me if I'm on track here...
It's a common issue. And one, in my opinion, that most people try to solve at the wrong level. When you think about it, this is a place where you need application logic to help determine access. Don't try to rely on infrastructure to solve this whole problem for you - it'll give you the tools, but you need to build the solution yourself (the J2EE spec doesn't know what your schema looks like!). Asking the J2EE infrastructure to do this for you is like asking the OS (NT or UNIX) to prevent specific users from editing files containing the word "gumbo." It would be something better implemented in the editor (the application), but using information provided from the OS - the user identity to make the decision. I would recommend the same approach with J2EE.
Here are several solutions:
1. Use the Session Facade pattern. Keep your entity beans wide open (no attribute based security), enable the use of Local interfaces on them and turn off remote access. This will generally protect them from anything not running in the same VM. Then, have your session bean execute custom finder methods on the ebeans that only return the proper instances for each user (which you can inspect with the getCallerPrincipal method in your session bean)... For example, your session bean extracts the principal, gets some identifying info about the user, then passes it on to the ebean finder method along with the actual search criteria. This should alleviate you having to sort through all of the beans (the DB and CMP mechanism will do it for you)
2. Another way to tackle this if you don't want to facade the entity bean with a session bean, is to use BMP. Then you can look at the caller principal in your finder methods (since you're writing them) and make the appropriate decisions.
3. If you're using CMP (which I'd recommend anyway) and still don't want to use the session facade (persistent, aren't you!), lock the findByPrimaryKey method using J2EE security to prevent arbitrary users from calling it, then write findXXX methods that take two arguments: the argument you want to search on, and a Principal object (representing the user identity). Then write the EJB-QL for the finder to filter based on key and identity. Set the security on these methods to a role that no actual user belongs to. Have all code calling these methods "run-as" that role -- use impersonation. That way, an arbitrary user won't be able to construct a fake principal object and call the method from outside your container.
4. This is a wild one... If using CMR (with EJB CMP 2.0) is something that excites you, create a User entity bean and a Product (or whatever) bean. In the user bean, create a getProductsByXXX method for a M:M relationship with the Product bean. Look up the user bean and traverse the values that way.
5. ... I can come up with some more, but I'm going to have to cut this post off now - I'm getting to article length! These should be good to get you started.
Bottom line is: The type of security you're looking for is extremely granular; It's a valid, realistic need, but super granular. So granular in fact that operating systems, databases, etc don't support it (you can't easily set security on a single row in a *standard* database table -- you have to use the view method I outlined above). The reason this generally isn't supported is because trying to build a generalized solution would slow things down too much and blur the role of the OS or DB. However, it's very attainable at the application level, as a matter of fact, it's probably part of the purpose of your application (to only display info relevant to a particular user).
Hope this helps! If I'm onthe wrong track here, let me know and I'll try to go ramble off on another tangent...
21 years ago

Originally posted by Deb Williams:
Are there any security issues when using dynamic or static includes? If so, is one better to use than the other?

Sorry I missed your post the first pass through... It was so concise and to the point, that I jumped right over it!
There really aren't any specific issues with jsp:include vs. <%@include... that should cause you excessive worry.
Some people might point out that the page include (the static, compile-time one) is nice because if you turn off automatic server-side recompilation and then batch compile all of your JSPs, an attacker could not force new functionality into your app merely by placing (or replacing) a JSP file on your server. If all you're doing is using includes for inclusion of static code, it's probably a good idea to stick with the static include. Understand though that if you do this and change one of the included files, on some containers, you'll have to manually force recompilation of all dependant JSPs.
But, there's a ton of stuff that you lose if you don't use dynamic includes, like the ability to look at the current request params, etc.
One thing to be careful of if you build resources that are meant to be dynamically included or forwarded to is to make sure that cross-context mapping is turned off for your application (only some web containers support this feature anyway). This will prevent other web apps from forwarding to or including your resources using RequestDispatcher and also inspecting your ServletContext object. Usually this isn't a problem, but an attacker could potentially take advantage of it.
Other than that, I can't add much more right now. However I could be overlooking a significant issue. Let me know if there's a specific one that you're concerned about and we can discuss it.
Thanks for posting!
21 years ago

Originally posted by Rick Salsa:

If you could that be great! So does the book cover programatic security as well? I'm assuming this might be something like isUserInRole, type of thing?
Also, you mentioned that the book talks about securing communcation from client to server, with a swing-jdbc app. What about securing communications with an app server using rmi? Is this mentioned at all and would it be similar to what you describe for the client-sever scenario?
Thanks Brian. The first answer was very informative!
[ October 23, 2002: Message edited by: Rick Salsa ]

Yup. The book does cover programmatic authorization in standalone, web based (servlet/JSP) and EJB pieces of an application.
Also, there's an entire chapter on implementing a security scheme with RMI. It covers everything from SSLizing your RMI connectivity to some examples of easy authentication/authorization schemes, to writing a custom socket factory for the RMI runtime to use.
Hope this answers your question!
21 years ago

Originally posted by Michael Yuan:

Hi Brian,
Thanks for the response! Can you tell us a bit more about what standards/examples you covered in your book? I think you probably have given examples on XML Encryption and XML Digital Signature. What tools do you use (JWSDP does not build-in tools ...)? Do you discuss the binding between secure XML protocols and SOAP?
Thanks a lot.

Thanks for the response!
The book covers J2EE web services security (in one chapter) as used by the Java application developer. We don't specifically discuss security in low level protocols like CORBA CSI, so we don't talk about XML-level sigs and encryption either (deciding to leave it to the folks who have an entire book to devote to the topic of web services security). We cover it at a high level instead and provide references.
The reason we made this decision is that Sun's best practice is for the app developer to use JAX-RPC to access web service based (synchronous) functionality. Doing this, the developer uses the JAX-RPC API to generate the SOAP message instead of composing it themselves. We felt that showing sample code for using XML-based security specs would be just like showing how to hand-write native CORBA stubs to access an EJB (passing credentials, etc) instead of letting the app server stub generator take care of it for us... Same with web services: The app developer usually doesn't compose native SOAP messages (although some probably do, just like some people like to write their own or modify other generated RPC stub code (IIOP, JRMP, etc)).
We do discuss the issues you mention at a high level though, and we also talk about how to secure SOAP messages used in a asynchronous, workflow based environment... But again, we didn't have space for copious sample code there either.
However, it'd be cool for someone to write a book about these topics because they're definitely interesting and underrepresented in the literature (I'd buy it!). We just didn't have time to delve that deeply into something we felt a minority of our readers would be interested in (we could have been wrong here though)...
Also, I've got to partially disagree with you:
The WSDP does contain security related features. You can programmatically use HTTP BASIC authentication (from JAX-RPC) to authenticate the client, HTTPS to secure the transport. In your web service, you can use declarative authorization to provide security for your endpoint, and if you need to be more granular you can also use the getUserPrincipal method in the ServletEndpointContext to make programmatic authorization decisions. All of this is supported in the WSDP. What isn't supported is the lower (transport) level stuff (like XML sig), and the evolving stuff (like WS-Security and SAML).
Additionally, on the humorous side, you mention "standards" for XML digital signatures, etc... I wasn't aware that any of these had cleared draft status yet... (Just kidding - In the web services arena a draft seems to be as good as a standard anyway...)
Hope this helps!! You've brought up some really good points that I'm sure many people have an interest in!
21 years ago

Originally posted by David O'Meara:
Welcome Brian!
Looks like you've settled in nicely!
For those who want to ask a question specific to the book, Brian has a thread you'll want to check out here, or you can start your own thread for non-specific questions.
I know everyone will join me in welcoming Brian and thanking him for taking the time to help us out!

Thanks David...
Whew! I'm already amazed at the volume and insightfulness of the questions people are asking. What a ton of fun
I may need to take a vacation by Thursday though... My fingers are already getting sore from typing!
21 years ago

Originally posted by subhit chauhan:
Does this book explains about the Java Cryptography... Is the Java Cryptography API's freely available. If yes then frm whr can i get that

Java Cryptography (I assume you're talking about the one from O'Reilly) by Knudsen is a good book and does explain the crypto side of Java in-depth. Of course, you can take a look at our book if you want examples of using cryptography in the context of a real application. The books actually complement each other well - Java Cryptography talks more about the theory of crypto and the JCE and our book focuses on the *application* of Java / J2EE security in general (of which cryptography and the JCE is an important part).
The crypto APIs (more commonly known as the JCE) are included with every version of J2SE 1.4 and above (you get them for free with the base JDK). If you want more algorithms and more comprehensive implementations, I'd recommend the Bouncy Castle JCE provider (available from
Hope this helps!
21 years ago

Originally posted by shai koren:
just a quick question i am not sure about.
Do CallbackHandller implementations have to have a no argument constructor?
It makes sense to me that they dont, because you need a way to pass parameters to populate username/password that right?
thanks in advance

Super question! JAAS can be confusing in this regard.
Here's a quick answer:
CallbackHandlers must have a no-arg constructor.
The callback handler is responsible for retrieving the uid and password from the user (or other source), so it's hard to pass those items to it at instantiation time... The handle method in the CallbackHandler is called with a particular callback (like PasswordCallback) when the prevailing LoginModule needs to retrieve the password info from the user. Most callback handlers then prompt the user or use some ofhter mechanism to generate this information.
In many cases the callback handler is constructed by the owning app and passed into the constructor for the LoginContext object (thus allowing constructors with arguments to be used). However, the default callback handler for the VM instance can also be specified by setting the auth.login.defaultCallbackHandler system property. If this mechanism is used, then the system will instantiate the callback handler and thus will need a no-arg constructor.
Hope this helps!
21 years ago

Originally posted by G Vanin:
Thanks Rajani,
I really have read only introduction to a subject, and the question really shifts to:
What is certificate, how the certificate authority ensures that it will not be exchanged. Is it sent by post?

Here are a couple of links to some online tutorials that explain this concept in more detail than I have room for here:
(follow the links at the left side of the page for various topics)
Hope this helps!!
21 years ago
I kind of assumed that Laksh was talking about ids or PKs for a database table, not actual User IDs... Stuff like productIDs, vendorIDs, stuff like that... I interpreted the question in the context that his main focus was not allowing the user to drive the web interface manually by modifying the address bar, not to specifically protect any information.
If we're talking about user IDs or other authentication credentials, I need to recompose my answer because none of my four points really apply.
Laksh, can you clarify your post for us? Thanks!!!
[ October 23, 2002: Message edited by: Brian Buege ]
21 years ago

Originally posted by Rick Salsa:
Hi Brian,
What's your take on the security interface used provided by most app servers? I have yet to use it in an application myself, but I'm told that is it very unflexible.
I guess I'm looking for something more dynamic that is configurable at runtime. From what I can make out, most container provided security features must be defined in descriptors when deploying.
Is there any way to get around this or do you need to roll your own?
Also, does the book mention securing client-server communication? How does that work, ssh tunneling?
Sorry for the load of questions. Thanks in advance!

Both great questions!!
Here are a few answers (I'll start from the bottom and work up):
The book includes working sample code for a Java-based SSL tunnel using the JSSE. It also discusses other tunneling products like stunnel. And it discusses them specifically in the context of securing a client-server app. AND, it has working sample code that includes a standalone client talking JDBC to a database, an applet client talking JDBC to a database, and a Java Web Start client talking JDBC to a database.
Next question:
I think that one of the common misconceptions about J2EE security is that it's inflexible. I haven't found that to be the case. There are some things that it doesn't do well, but that's the case with any product.
For example, in SQL it's hard to do some things, but most people would think you were nuts if you suggested rolling your own database. It's kind of the same with J2EE security. There's some stuff that isn't elegant, but I haven't found anything that I couldn't work around yet... Again, just like SQL queries.
J2EE security provides for both declarative (specified in the deployment descriptor) and programatic (handled at runtime) authorization. This allows you to have the best of both worlds: For simple stuff, you can use the authorization in your DD, then when you need to get dynamic, you can interrogate your container to find the identity of the person calling your method and make authorization decisions in your code.
With the advent of JAAS in the newest app servers, this dynamic capability is increased even further and the possiblities are pretty endless.
If you'd like me to be more specific about any of the generalizations I've made above, let me know...
[ October 22, 2002: Message edited by: Brian Buege ]
21 years ago