You would need to provide more information on what you are trying to accomplish. I.e. what do you need user identity for? Is it just to authorize access to the resource or your response depends on user identity attributes - age, service contract level, etc. Without that I can only give you very general response. First, for anonymous users it is pretty strightforward - you just don't have user idientity in the http request. For authenticated users it is a bit more complicated. Generally speaking you have portal as identity provider i.e. party responsible for user authentication and your REST service as a service provide that needs to accept request made on identity provider behalf. There are number of ways to pass user idenity - either in the http header or even as request parameter. This part is easy you ca use a simple servlet filter to extract the identity. The challenge here is that your service needs to 'trust' the identity supplied in the http request. If it is to simply authorize access to the resource something like oAuth may work well for you. JBoss RestEasy can handle oAuth tokens for you. Or you can have some security gateway component e.g. Siteminder or Webseal in front of your service handle SSO with portal container and authorize access to the protected resource(s). In more complicated scenario service provider typically requires access to user identity attributes. The right solution depends on your requirements. It could be as simple as SAML assertion in the http header signed for trust purposes. A security gateway can do the job of generating SAML assertion and inserting idenity attributes. Or it could be a signed reference to the resource your service has to call to retrieve identity attributes. I have also seen implementations using private resources i.e. something like http://hostname/rest/HelloWorldRest/<user idenity>/hello. Identity provider can supply reference(s) to the private resource(s) via hypermedia links.
If you don't mind being dependent on the underlying portal container, I believe you can use
ConversationState state = ConversationState.getCurrent();
In order to be authenticated you need to access the private context so for the helloworld service you mentioned it would be
Thank you Guys for your time and for the answers! It everything is true - no doubts about it.
In regards to Andrei suggestion to give more details on this topic I've prepared a simple picture ( as a picture is worth of thousand words ) to give more details about the context (hope it does).
We are not planned (yet) to use any external IDM or oAuth - for the time being. I'd like to leverage a GateIn's standard authorization mechanisms. Means if a user is already logged into the application, can view a portlet (jsp+ajax+extJS). The portlet, to be more precise, the extJS stuff will make call to a RESTful service exposed via GateIn way.
My basic question is, how to make that the REST service will be informed that the request came from logged user (from logged user's portlet) ?
http://localhost:8080/rest/private/HelloWorldRest/hello - even though we access the resource through the private we are being asked for input user/password - it isn't desired effect in our case (storing plain password at client side isn't a solution)
There is also another way to expose REST services - via RestEasy. As a matter of fact our app's stack utilize Seam/EJB3 so RestEasy is also an option. Creation of a REST services via RestEasy is even easier then in GateIn way - but the more ingridients the more potential risk of misunderstanding, especially that Seam tends to make many things behind the scene (-: - that's why we've ve chosen the GateIn way as a first approach - to gain better understanding of SSO stuff.
If we succeed with this story I think it would be a good marerial to write a smal article, because REST and DataCentric approach seems is getting more popular day-by-day.
I'm wondering if you were thinking about using serveResource ( in your portlet ) instead of a Rest service for your usecase.
Actually, i don't really get why you chose using Rest for the usecase which the Rest service only serves your portlet, right ?