I also apologise if this is a Tomcat issue, but it IS an issue with the 2.1b2 bundle you provide for download.
Thanks,
Tim
Nick Longinow wrote on 03/11/04 01:26 PM:
Hi,
Again, apologies for what may be a Tomcat issue, but...
Per Tomcat's documentation, I am trying to set the credentials for the admin and manager webapps that ship with Tomcat. I've added them to the tomcat-users.xml file (root/root), but when I try to login to http://localhost:8080/admin I get a stack dump like this:
WARNING: Login exception authenticating username root javax.security.auth.login.LoginException: org.apache.slide.common.DomainInitializationFailedError: Domain initialization error : Domain.xml (The system cannot find the file specified)
Any ideas ?
Nick
-----Original Message-----
From: Ryan Rhodes [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 12:58 PM
To: [EMAIL PROTECTED]
Subject: RE: Custom authorization and authentication best practices
John,
Well, it looks like there are three cases we need to handle and we are only handling one of them. Right now the username/password/url are coming from the connection spec. They can also come from configuration properties.
The case I need is when the credentials come from the JAAS Subject as a: javax.resource.spi.security.PasswordCredential.
I don't think that the JCA specifications are clear on exactly which credentials should be used when they are supplied through more than one method.
I'm using JBoss. I'm pretty sure the PasswordCredential should work the same under weblogic because I was using a lot of weblogic docs for info. I think weblogic also supports caller impersonation.
I was really hoping somebody could shed some light on making the url configurable. I'm doing it from a config property right now like you said.
That means I can only set the url to the slide root. I'm then using WebdavResource.getChildResources() to navigate down, but I feel like that might be doing a whole bunch of extra round trips, when I usually only want one resource at a time.
Whats the best way to do this?
Regards,
-Ryan Rhodes
From: "John Gilbert" <[EMAIL PROTECTED]> Reply-To: "Slide Users Mailing List" <[EMAIL PROTECTED]> To: "Slide Users Mailing List" <[EMAIL PROTECTED]> Subject: RE: Custom authorization and authentication best practices Date: Wed, 3 Nov 2004 12:22:20 -0500
Ryan,
What kind of changes are you looking to do for the jca connector? I was thinking of doing the same thing. For example, providing a property for the url and using container managed authentication.
Also, are you using weblogic?
- John
-----Original Message----- From: Ryan Rhodes [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 11:31 AM To: [EMAIL PROTECTED] Subject: RE: Custom authorization and authentication best practices
Hi Morten,
I'm working on something similar to this right now. One way it "Could" be done is this.
1) Use a JAAS Login module to make slide the authentication realm for the web container. This way users and roles are pulled from Slide for web applications.
2) Use the JCA Connector to connect web applications to Slide.
3) Use a second JAAS login config for the JCA Connector. JCA supports 3 or 4 different types of authentication. The type called "Caller Impersonation" allows you to pass on the user/roles from the calling web/ejb application to be used by the JCA connection. This way you don't have to keep around the username/password from the web login to re-use with Slide. The application server handles it for you, and the web user will automatically be limited to whatever document permisions they have in slide.
Right now, the JCA Connector doesn't support any type of declarative configuration. The login/pass are passed programatically through the WebDavConnectionSpec when you create a connection.
When I finish making it configurable I'll submit the changes, but I'll warn you that (#3) will always require configuration that is specific to the application server. Not every app server supports Caller Impersonation, and I think (#1), at least on Jboss, requires a JAAS Login Module that uses propriertary JBoss libraries and I heard those can't be mixed with Apache License, so... it probably won't be support by Slide.
Hope that Helps,
Ryan Rhodes
From: Morten <[EMAIL PROTECTED]> Reply-To: "Slide Users Mailing List" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Custom authorization and authentication best practices Date: Mon, 01 Nov 2004 19:15:34 +0100
Hi.
I will be using Slide as a file system based content repository. It
will be
part of a web-application which contains a UI to add/remove users and
set
permissions at folder level.
This means I need to integrate Slide with my web-app. I see 2 possible methods:
1. Slide accesses an external data-source for authentication and authorization, possibly via a custom plug-in (could be done using WCK,
but
that impacts DeltaV).
2. The users and permissions get set in Slide explicitly using an API (pointers to which greatly appreciated).
Functionally, I need to be able to answer the questions "Is user X with
password Y a valid user?" and "Can user X access folder Z?"
Which of the above is the preferred approach and what is the "proper"
way
to go about it? What's considered best practices? Studying WCK, Realms,
JAAS, Projector gives lots of options on authentication, but I fail to
find
options for authorization.
Br,
Morten
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
