users@jersey.java.net

Re: [Jersey] Full-fledged SSL under Jersey

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 09 Mar 2009 15:34:51 +0100

On Mar 4, 2009, at 7:00 AM, Gili wrote:

>
> FYI, I just got a detailed answer from someone on the Glassfish forum:
> http://forums.java.net/jive/message.jspa?messageID=334958#334958
>

... and with Jersey one can use @RolesAllowed.

See:

   https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.2/api/jersey/com/sun/jersey/api/container/filter/RolesAllowedResourceFilterFactory.html

Paul.

> Gili
>
>
> Marc Hadley wrote:
>>
>> On Mar 2, 2009, at 8:37 PM, Gili wrote:
>>>
>>> It's not clear how users, groups and roles are related in Glassfish.
>>>
>>> Glassfish's sun-web.xml lets you associate multiple principals and
>>> groups
>>> with each role, but it's not clear how to get at that information
>>> using
>>> javax.ws.rs.core.SecurityContext. SecurityContext lets you get the
>>> user
>>> principal, but how do I get the list of groups and roles associated
>>> with
>>> this principal? I can't seem to find good documentation on this
>>> topic. Any
>>> ideas?
>>>
>> I'm no security expert so take this with a grain of salt but I think
>> the idea is that rather than getting a list of groups and roles you
>> check SecurityContext.isUserInRole for whatever role is needed to
>> access the protected resource. IOW, you base your security decisions
>> on roles alone.
>>
>> Marc.
>>
>>> Steve Sims wrote:
>>>>
>>>> Hi Gili,
>>>>
>>>> I've only written a test harness (using the pre-Jersey 1.0.2
>>>> HttpURLConnection based client not the new Apache based one) to
>>>> communicate with my local machine using HTTPS, so I don't known too
>>>> much
>>>> about Java's security mechanisms but basically, Java keeps its
>>>> trusted
>>>> certificates in keyfiles that are modified using the keytool
>>>> application
>>>> supplied with the Java distribution and therefore if you have a
>>>> trusted
>>>> certificate for the server imported, or the certificate's been
>>>> issued by
>>>> a certificate authority whose certificate is in the trust store,
>>>> then it
>>>> should take care of everything for you when you open up a
>>>> connection.
>>>>
>>>> If you don't have a trusted CA signed (i.e. commercial) certificate
>>>> then
>>>> you can create a keyfile containing your server's key and
>>>> distribute
>>>> that along with the client. I did the following within my test
>>>> harness:
>>>>
>>>> 1) Point firefox towards https://localhost:8081/v1/core/
>>>> 2) Click Tools->Page Info
>>>> 3) Click the Security tab
>>>> 4) Click the View Certificate button
>>>> 5) Click the Details tab
>>>> 6) Click the Export button and export the file as a PEM to
>>>> somewhere
>>>> 7) Bring up a shell to the place that the PEM file is stored
>>>> 8) Create a new keyfile: keytool -importcert -alias "localhost" -
>>>> file
>>>> localhost.pem
>>>> 9) Enter a password for the file such as "adminadmin"
>>>>
>>>> You then need to supply some system properties in order to get the
>>>> JVM
>>>> to load your keystores. Also, if you're testing on the local
>>>> machine,
>>>> because there's no DNS to resolve "localhost", I have to do the
>>>> following test only HostnameVerifier hack:
>>>>
>>>> HttpsURLConnection.setDefaultHostnameVerifier(
>>>> new javax.net.ssl.HostnameVerifier() {
>>>>
>>>> public boolean verify(String hostname, SSLSession sslSession) {
>>>> if (hostname.equals("localhost")) {
>>>> return true;
>>>> }
>>>> return false;
>>>> }
>>>> });
>>>>
>>>> System.setProperty("javax.net.ssl.keyStore", <generated keystore
>>>> filename>);
>>>> System.setProperty("javax.net.ssl.keyStorePassword", "adminadmin");
>>>> System.setProperty("javax.net.ssl.trustStore", <generated keystore
>>>> filename>);
>>>> System.setProperty("javax.net.ssl.trustStorePassword",
>>>> "adminadmin");
>>>>
>>>> There are ways to programmatically update the default keystore
>>>> however
>>>> using classes such as java.security.KeyStore etc.
>>>>
>>>> It helps, whilst trying to get it working to turn on the debug as
>>>> well:
>>>>
>>>> System.setProperty("javax.net.debug", "ssl,handshake,record");
>>>>
>>>> Anyway, there's lots of information here that will explain things
>>>> better
>>>> than I have - there's just a lot to it! :
>>>>
>>>> http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
>>>>
>>>> As far as the username and password issue goes, are you talking
>>>> about
>>>> HTTP BASIC authentication? If so, the new Apache based Jersey
>>>> client is
>>>> probably the way to go, see
>>>> https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=4165
>>>>
>>>> Hope this helps a little, it's quite a big area and took me a while
>>>> to
>>>> just get something working - then as soon as I had it I moved on!
>>>>
>>>> Steve
>>>>
>>>> Gili wrote:
>>>>> Hi,
>>>>>
>>>>> What is the best way to communicate over SSL using Jersey? I
>>>>> expect the
>>>>> client to:
>>>>>
>>>>> 1) Request and verify the server certificate
>>>>> 2) Encrypt and send the data to the server
>>>>>
>>>>> I have the following questions:
>>>>>
>>>>> - How do I request the server certificate (assuming it is found in
>>>>> a CA)?
>>>>> - How do I verify it?
>>>>> - How do I configure an event listener to prompt me for a user
>>>>> name and
>>>>> password when it's needed?
>>>>> - Do I need a commercial SSL certificate? Do I lose anything by
>>>>> hard-coding
>>>>> my public key into the client? Granted I'll need to issue new
>>>>> clients if
>>>>> the
>>>>> server key changes, but is there anything else?
>>>>>
>>>>> Thank you,
>>>>> Gili
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/Full-fledged-SSL-under-Jersey-tp2402900p2412855.html
>>> Sent from the Jersey mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/Full-fledged-SSL-under-Jersey-tp2402900p2420562.html
> Sent from the Jersey mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>