users@glassfish.java.net

Re: JAX-RPC servlet endpoint with HTTP basic auth & SSL

From: Ryan de Laplante <ryan_at_ijws.com>
Date: Tue, 13 May 2008 23:51:20 -0400

Remember I mentioned and other server that has SJSAS 9.1 FCS and a bunch
of other weird problems with my JAX-RPC web service & URLs? I installed
9.1 UR2 on there and the JAX-RPC service.

Now the behavior on both servers is consistent. I definitely have a
security role called "centralData" that contains at least one user in a
group called IJWAPPS. When I deploy my service .war GlassFish gives
the following error:

No Principals mapped to Role [IJWAPPS]

When I try to access the WSDL on http, it automatically redirects me to
https (that's how web.xml is configured). When i get to the https URL,
it asks for username/password. I enter the correct username and
password, then it gives me the 403 Forbidden error. The server also
logs the long error message I posted below.

Can someone please confirm this is a bug in the app server or JAX-RPC?
Do I need to create a ticket to have someone look at it?


Thanks,
Ryan


Ryan de Laplante wrote:
> That's a good clue. I did find an error in the logs:
>> No Principals mapped to Role [IJWAPPS].
> I looked in the web admin console at the centralData security realm.
> There are two users, both with IJWAPPS group associated with them. I
> copy/pasted the security part of web.xml from a JAX-WS service that
> uses the same security realm. It works fine, so it doesn't make sense
> that this JAX-RPC service isn't able to find users.
>
> When I try to access the WSDL, enter the username/password and get the
> 403 Forbidden error, this shows in the log file:
>
> JACC Policy Provider: PolicyWrapper.implies,
> context(MyService/MyService)-
> permission((javax.security.jacc.WebUserDataPermission /MyService GET))
> domain that failed(ProtectionDomain (file:/MyService/MyService <no
> signer certificates>)
> null
> <no principals>
> java.security.Permissions_at_1f02555 (
> (javax.security.auth.PrivateCredentialPermission
> javax.resource.spi.security.PasswordCredential * "*" read)
> (javax.management.MBeanPermission [com.sun.messaging.jms.*:*] *)
> (java.net.SocketPermission localhost:1024- listen,resolve)
> (java.net.SocketPermission * connect,resolve)
> (unresolved javax.security.jacc.WebUserDataPermission /*
> DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE:CONFIDENTIAL)
> (unresolved javax.security.jacc.WebUserDataPermission /*
> !DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE)
> (unresolved
> com.sun.corba.ee.impl.presentation.rmi.DynamicAccessPermission access
> null)
> (unresolved javax.security.jacc.WebResourcePermission /*
> !DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE)
> (unresolved com.sun.enterprise.security.CORBAObjectPermission * *)
> (javax.management.MBeanTrustPermission register)
> (java.util.PropertyPermission line.separator read)
> (java.util.PropertyPermission java.vm.version read)
> (java.util.PropertyPermission java.vm.specification.version read)
> (java.util.PropertyPermission java.vm.specification.vendor read)
> (java.util.PropertyPermission java.vendor.url read)
> (java.util.PropertyPermission java.vm.name read)
> (java.util.PropertyPermission * read,write)
> (java.util.PropertyPermission os.name read)
> (java.util.PropertyPermission java.vm.vendor read)
> (java.util.PropertyPermission path.separator read)
> (java.util.PropertyPermission java.specification.name read)
> (java.util.PropertyPermission os.version read)
> (java.util.PropertyPermission os.arch read)
> (java.util.PropertyPermission java.class.version read)
> (java.util.PropertyPermission java.version read)
> (java.util.PropertyPermission file.separator read)
> (java.util.PropertyPermission java.vendor read)
> (java.util.PropertyPermission java.vm.specification.name read)
> (java.util.PropertyPermission java.specification.version read)
> (java.util.PropertyPermission java.specification.vendor read)
> (java.lang.RuntimePermission getClassLoader)
> (java.lang.RuntimePermission loadLibrary.*)
> (java.lang.RuntimePermission accessDeclaredMembers)
> (java.lang.RuntimePermission getProtectionDomain)
> (java.lang.RuntimePermission modifyThreadGroup)
> (java.lang.RuntimePermission stopThread)
> (java.lang.RuntimePermission setContextClassLoader)
> (java.lang.RuntimePermission queuePrintJob)
> (java.io.FilePermission C:\Users\ryan\AppData\Local\Temp\\- delete)
> (java.io.FilePermission D:/Program
> Files/Sun/AppServer91UR2/domains/domain1\lib\databases\- delete)
> (java.io.FilePermission <<ALL FILES>> read,write)
> )
> )
>
> Someone else from Sun said:
>
>> For JAXRPC, we have not done too much to address this virtual server
>> cases. Best option will be to manually edit the WSDL in
>> domains/domain1/generated/..... directory.
>>
>> Vijay
> I had the https listener for the default server disabled since it
> wasn't being used. I re-enabled it, restarted the app server,
> redeployed my app. When I try to access the WSDL on http, it sends me
> to https. Excellent. After typing in a username/password I get the
> forbidden error. Hopefully we can get this principal-to-role issue
> figured out.
>
>
> An other interesting find: in web admin console, Applications-->Web
> Applications, I click the service web app to look at the settings.
> Instead, a different web app is displayed and highlighted in the tree
> on the left. No matter how I try, I can't get the web admin console
> to display this web app for me to view/change settings!
>
>
> Thanks,
> Ryan
>
>
>
>
> glassfish_at_javadesktop.org wrote:
>> it looks like at the time you deployed your app, there was no
>> principal-2-role mapping in effect for role IJWAPPS. You can probably
>> confirm this by looking for a warning message in server.log. I don't
>> think that fully explains what you are seeing. but it explains, for
>> example, why you had a problem if get was include in the list of
>> constrained methods.
>>
>> so as a first step make sure you define a principal-2-role mapping
>> for role IJWAPPS, and map your users to it, preferabbly by mapping a
>> sgroup of which your users are a member, to the role. You must
>> redeploy your app after doing this, You should see a change in the
>> policy file. attach the new granted.policy file to this thread, and
>> the new error msgs that occur when you try to access your endpoint.
>>
>> Ron