<< Back to previous view

[XWSS-27] SecurityConfigurationXmlReader ignores digestPassword in xml Created: 08/Apr/08  Updated: 08/Apr/08  Resolved: 08/Apr/08

Status: Resolved
Project: xwss
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jarol1 Assignee: xwss-issues
Resolution: Incomplete Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 27
Tags:
Participants: jarol1, kumarjayanti and xwss-issues

 Description   

I found a bug in SecurityConfigurationXmlReader - it ignores digestPassword
attribute, which is mentioned in ConfigurationConstants.java. As a result,
plaintext password which can be found in <Username> element of
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"
is not supported (only digested works). Exception WSS1404.notmet.digested will
be thrown.

Example SOAP that is rejected (it was generated by Oracle BPEL):

"<soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"
xmlns:wsu=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\"><soap:Header><wsse:Security
xmlns:wsse=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\"
xmlns=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\"
xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\"
soap:mustUnderstand=\"1\"><wsse:UsernameToken
xmlns:wsse=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\"
xmlns=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\"><wsse:Username>XXXXXXXXX</wsse:Username><wsse:Password
Type=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText\">XXXXXXXX</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body
xmlns:ns1=\"http://xmlns.oracle.com/transferCredit\"><ns1:transferCreditProcessRequest><ns1:destination_deviceid>XXXXXXX</ns1:destination_deviceid><ns1:sum>0.001</ns1:sum></ns1:transferCreditProcessRequest></soap:Body></soap:Envelope>";

I used XWSS 2.0 style configuration:

"<xwss:SecurityConfiguration dumpMessages=\"true\"
xmlns:xwss=\"http://java.sun.com/xml/ns/xwss/config\"><xwss:UsernameToken
digestPassword=\"false\"
/><xwss:RequireUsernameToken/></xwss:SecurityConfiguration>";



 Comments   
Comment by jarol1 [ 08/Apr/08 04:25 AM ]

Close this issue, the correct configuration is:

"<xwss:SecurityConfiguration dumpMessages=\"true\"
xmlns:xwss=\"http://java.sun.com/xml/ns/xwss/config\"><xwss:UsernameToken
useNonce=\"false\" digestPassword=\"false\"/><xwss:RequireUsernameToken
nonceRequired=\"false\"
passwordDigestRequired=\"false\"/></xwss:SecurityConfiguration>";

Comment by kumarjayanti [ 08/Apr/08 04:40 AM ]

closing the issue as suggested by user.





[GLASSFISH-4779] iiop-listener ip address ignored Created: 16/Apr/08  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: jarol1 Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,779
Tags: 3_1-exclude
Participants: chaoslayer, harpreet, Harshad Vilekar, jarol1 and Ken Cavanaugh

 Description   

In my domain.xml I have defined 2 additional unencrypted orb listeners on ports
3701 and 3702 on different IP addresses. But when I start glassfish, my settings
are ignored, and iiop service works only on 10.20.32.51 (on ports 3700, 3701,
3702 - I didn't want that!) even though I selected other IP addresses for other
listeners. Server has multiple network cards, 2 of them in bond. It has
10.20.32.51 (bond), 10.10.32.151 and 127.0.0.1. I need the iiop to work on all
IP addresses, but on different ports. Using 0.0.0.0 doesn't have the required
effect, since then I can't jndi from remote machine on 10.10.32.151.

<iiop-service client-authentication-required="false">
<orb max-connections="1024" message-fragment-size="1024"
use-thread-pool-ids="thread-pool-1"/>
<iiop-listener address="0.0.0.0" enabled="true" id="orb-listener-1"
port="3700" security-enabled="false"/>
<iiop-listener address="10.10.32.151" enabled="true" id="orb-listener-2"
port="3701" security-enabled="false"/>
<iiop-listener address="10.20.32.51" enabled="true" id="orb-listener-3"
port="3702" security-enabled="false"/>
<iiop-listener address="0.0.0.0" enabled="true" id="SSL" port="3820"
security-enabled="true">
<ssl cert-nickname="s1as" client-auth-enabled="false"
ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true"
tls-rollback-enabled="true"/>
</iiop-listener>
<iiop-listener address="0.0.0.0" enabled="true" id="SSL_MUTUALAUTH"
port="3920" security-enabled="true">
<ssl cert-nickname="s1as" client-auth-enabled="true"
ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true"
tls-rollback-enabled="true"/>
</iiop-listener>
</iiop-service>

This bug is present in both Glassfish V2ur2 and Glassfish V2ur1.



 Comments   
Comment by harpreet [ 20/Oct/08 09:34 AM ]

Please scrub issue and see if it is critical to v2.1.

Comment by Ken Cavanaugh [ 28/Oct/08 05:09 PM ]

The current ORBManager code uses the old LISTEN_SOCKET_PROPERTY to initialize
the acceptor list, and the old API does not support a hostname, so we do not
really support multiple network interfaces very well. The ORB actually supports
the needed functionality internally, and we simple need to add a new
transport SPI in TransportDefault, which can be used to create an appropriate instance
of SocketOrChannelAcceptorImpl. This can then be registered with the TransportManager
during ORB initialization using the GlassFish ORB configurator.

As this is not critical for GFv2.1, I am moving it to V3.

Comment by Ken Cavanaugh [ 30/Oct/08 11:55 AM ]

Moving to V3 (missed the target milestone update).

Comment by Ken Cavanaugh [ 30/Oct/08 11:56 AM ]

Still trying to remove from 9.1.1.

Comment by Ken Cavanaugh [ 22/Sep/09 05:05 PM ]

Moving to v3.1, although the new approach of creating acceptors
directly should support this much more easily than the old
properties-based approach.

Comment by Ken Cavanaugh [ 06/Oct/09 01:53 PM ]

Needs v3_exclude in status whiteboard to exclude from v3.

Comment by Ken Cavanaugh [ 23/Mar/10 12:24 PM ]

Moved to v3.1.

Comment by chaoslayer [ 18/Feb/11 03:17 AM ]

This has been initially reported as GLASSFISH-16, back in 2005. So almost 6 years (!!!) and no solution for this problem?

So, GlassFish (including the upcoming 3.1 release) MUST secured externally. And still a risk is still there.

Please, guys, fix it.

Comment by chaoslayer [ 18/Feb/11 03:20 AM ]

Also I've noted, that the one that is initialized lazy actually IS bound to a specific interface:

tcp6 0 0 ::1:3700 :::* LISTEN 1000 28061662 5202/java





[GLASSFISH-4608] Unexpected Principal in SecurityContext Created: 04/Apr/08  Updated: 23/Oct/08  Resolved: 23/Oct/08

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur1
Fix Version/s: 9.1.1

Type: Bug Priority: Major
Reporter: jarol1 Assignee: raharsha
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,608
Status Whiteboard:

911ToScrub

Tags:
Participants: harpreet, jarol1, kumarjayanti and raharsha

 Description   

I have an application that uses Quartz for job scheduling started via servlet
QuartzInitializerServlet which is automatically started during server startup or
deployment and init(ServletConfig cfg) is called.

The problem is, when undeploying and deploying application from netbeans (which
is done under "admin" user using
org.apache.tools.ant.taskdefs.optional.sun.appserv.DeployTask via ant), the
init() method of servlet is executed under Principal "admin", and not under
"ANONYMOUS" as it is done when server is restarted. This creates problems
because then jobs run under different Principals depending on how was
application initialized (via server startup or redeployment).

When you call SecurityContext.getCurrent().getCallerPrincipal(); in init()
method of a servlet with <load-on-startup>1</load-on-startup> in web.xml, the
bug manifests itself.

I believe SecurityContext should be switched to default unathorized context when
initializing web application modules even when redeploying applications.

This problem was detected in Glassfish V2ur1. I haven't tested V2ur2.



 Comments   
Comment by harpreet [ 20/Oct/08 09:31 AM ]

Please scrub issue and see if it is critical to v2.1.

Comment by kumarjayanti [ 23/Oct/08 05:03 AM ]

the problem can be workedaround by configuring an unprivileged @RunAs for the
QuartzInitializerServlet.

The Java EE spec may not allow one to specificy an anonymous role as the run-as
role, but they could certainly configure the initializer to run with an
unprivileged role.





Generated at Sat Apr 19 03:38:32 UTC 2014 using JIRA 4.0.2#472.