[jira] Updated: (AXIS2-581) Pluggable security/authentication support

["Jens Schumann (JIRA)" <ji...@apache.org>]

     [ 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