[ http://issues.apache.org/jira/browse/AXIS2-581?page=all ]
Jens Schumann updated AXIS2-581:
--------------------------------
Attachment: admin-console-proposal.tar.gz
Attached a proposal which tries to improve the current web app regarding this
issue (AXIS2-581) and AXIS2-334 and AXIS2-578. The current attached patch
include:
1. Separated public web app operations (listService/listService/wsdl access)
from non public web app requests
2. Moved admin operations to /admin/ requests for better distinction to public
/services/ getter requests.
3. Moved jsp content to a sub directory within the web app (axis2-web) in order
to improve embeddability. The move is done in maven build in order to help me
get JSP updates while working on it. However I would recommend to move all JSP
pages in SVN instead.
4. Moved upload logic to from JSP to java
5. Support disabling build-in axis2 security. In combination with 1&2 users can
now disable username/passwd check based on axis2.xml and use their own
authentication mechanism based on URL (such as standard web security).
Introduced new parameter <parameter name="disableAdminSecurity"
locked="false">true</parameter> for axis2.xml therefore.
6. Fixes AXIS2-334 - "Invalid Logging". If a user session is not valid anymore
the user will be prompted to enter username/passwd instead of seeing a
stacktrace.
7. Enables public WSDL and Service rendering after removing this capability
yesterday. Deepal: Somehow you removed this capability by removing GET Support
of AxisServlet
8. Fixed a few spelling errors . There are still lots of them.
9. Fixed most obvious HTML errors.
Current drawbacks:
- It's still a quick and dirty web app with lots hard coded strings in java
code and in web app. This includes URL rendering for WSDL requests too.
- In order to get JSP rendering working based on ServletDispatcher#forward() I
have to set <base href=.." /> in HTML. The current implementation assumes
HttpServletRequest#getServerName() and HttpServletRequest#getServerPort() etc.
return the appropriate public visible web app URL. Usually this is not the case
if you use Apache mod_proxy or use transparent SSL handling outside the web
container. Currently the web app does not handle this too, nevertheless it does
not break completly.
- I did not test the current implementation with web apps bound to servlet
context root "/". I believe that the current <base href=".."> reference might
cause issues.
Any comments?
> Pluggable security/authentication support
> -----------------------------------------
>
> Key: AXIS2-581
> URL: http://issues.apache.org/jira/browse/AXIS2-581
> Project: Apache Axis 2.0 (Axis2)
> Type: Wish
> Components: Tools
> Versions: 0.95
> Reporter: Jens Schumann
> Attachments: admin-console-proposal.tar.gz
>
> Right now axis2 uses a proprietary security mechanism for authenticating
> users. The current mechanism has two drawbacks:
> 1. It requires setting username/password in axis2.xml, which will be done
> BEFORE build time. Having username/passwds within a deployment units isn't
> the best way to do it.
> 2. As seen in AXIS2-580 the security check can be easily broken by new code
> in axis2.
> I recommend to rebuild the security implementation from scratch and create
> either
> A) a pluggable security mechanism that lets users replace the security
> mechanism with their own authentication mechanism or
> B) use standard web security.
> Of course B will have consequences for the current axis2.war - it won't be
> that easy to create a drop-in web archive which will work accross all web
> containers . However I would appreciate if axis2 would support it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
