Page 1 of 1

About Question enthuware.ocejws.v6.2.226 :

Posted: Sat Sep 17, 2016 11:56 am
by victor2016
Hi,

Sorry but I don't understand this requirement: "Define the root resource class as an Singleton EJB." I am researching this issue but cannot find an answer on what Singleton EJB has to do with role based JAX-RS authentication? I understand other requirements but have a gap in knowledge regarding EJB connection with respect to JAX-RS. Could you kindly explain a bit?

Thanks,
Victor.

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Sun Sep 18, 2016 2:08 pm
by fjwalraven
You definitely should read and study (a bit) about EJBs and Java EE-security. The EE6-tutorial is a good starting point: http://docs.oracle.com/javaee/6/tutorial/doc/

Regards,
Frits

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Sun Sep 18, 2016 2:17 pm
by fjwalraven
When you define an EJB as a JAX-RS root resource class you can use the EE6 security features an EE6 server provides you (like method based access control).

Nice EE6-security overview: http://docs.oracle.com/javaee/6/tutorial/doc/bnbwk.html

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Sun Sep 18, 2016 3:02 pm
by victor2016
fjwalraven wrote:When you define an EJB as a JAX-RS root resource class you can use the EE6 security features an EE6 server provides you (like method based access control).

Nice EE6-security overview: http://docs.oracle.com/javaee/6/tutorial/doc/bnbwk.html
Hi,

Thank you for these resources. I also found discussion on this question (duplicate?) here: viewtopic.php?f=40&t=2535 which is also quite helpful.

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Sun Sep 18, 2016 3:37 pm
by fjwalraven
That is indeed a similar question (not a duplicate).

Regards,
Frits

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Tue Nov 15, 2016 1:01 pm
by sttaq0442
fjwalraven wrote:That is indeed a similar question (not a duplicate).

Regards,
Frits
Am I right in thinking that the Role based security is only possible in EJB container i.e. when your service is annotated with @Stateless or @Singleton?

Otherwise, if it can be achieved without EJB then following option will be correct:

Add a security constraint in the web deployment descriptor to restrict certain URL's.

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Wed Nov 16, 2016 12:02 am
by fjwalraven
Am I right in thinking that the Role based security is only possible in EJB container i.e. when your service is annotated with @Stateless or @Singleton?
Yes, you are right!

Regards,
Frits

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Wed Nov 16, 2016 6:16 am
by sttaq0442
fjwalraven wrote:
Am I right in thinking that the Role based security is only possible in EJB container i.e. when your service is annotated with @Stateless or @Singleton?
Yes, you are right!

Regards,
Frits
The first option is "Add a security constraint in the web deployment descriptor to restrict certain URL's. The explantaion says that this is not needed but am I right in thinking that it CAN ALSO be used using the following config? We would, however, still need to map the users to the roles in a xxx-web.xml file.

Code: Select all

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Protected Area</web-resource-name>
        <url-pattern>/jsp/security/protected/*</url-pattern>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>manager</role-name>
    </auth-constraint>
</security-constraint>

 <!-- Security roles used by this web application -->
<security-role>
    <role-name>manager</role-name>
</security-role>
<security-role>
    <role-name>employee</role-name>
</security-role>

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Wed Nov 16, 2016 2:16 pm
by fjwalraven
Yes, you can do that however you can't restrict a single method of a specific RESTful class and that is what is required by the problem statement:
We want to use role based security on a method of a RESTful Web Service.
Regards,
Frits

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Thu Nov 17, 2016 5:47 am
by sttaq0442
fjwalraven wrote:Yes, you can do that however you can't restrict a single method of a specific RESTful class and that is what is required by the problem statement:
We want to use role based security on a method of a RESTful Web Service.
Regards,
Frits
Thanks Frits.

Its a tricky one. I missed the clue "a method" and even with this clue and the understanding that every methd can have its own URL makes me feel that the first option is also correct. So for example, we can restrict a method by restricting it's URL which is equivalent to the statement "role based security on a method". However, in this manner we can also restrict many URLs at once but it really depends on the expression we use in the web.xml and this expression is not given in the answer so we are open to guessing what the examiner may be thinking?

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Thu Nov 17, 2016 1:27 pm
by fjwalraven
So for example, we can restrict a method by restricting it's URL which is equivalent to the statement "role based security on a method"
Be careful here: it is not equivalent.

Check this example:

Code: Select all

@Path("convert")
public class RunningConverter extends MyJAXRS_Classes {
	@GET
	@Produces("text/plain")
	public String getPlainTextResultTimeInSeconds(@QueryParam("me") double metres,
			                                  @QueryParam("km") double kmPerHour) {
             // implementation
	}

	@GET
	@Produces("text/html")
	public String getHTMLResultTimeInSeconds(@QueryParam("me") double metres,
			                             @QueryParam("km") double kmPerHour) {
             // implementation
	}
}
Both implementations react on the same URL, however depending on the Accept string it will return the result from the PlainText method or from the HTML method. There is no way you can restrict 1 of the 2 methods using URL restriction.

Regards,
Frits

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Thu Nov 17, 2016 1:45 pm
by sttaq0442
that is interesting example. Thanks for the explanation.

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Mon Jun 11, 2018 1:42 pm
by witek_m
hello, I tried to make simple example about this question, but I cannot make it works withoud security-constraint. I Have a resource class with @Stateless annotation and method with @RolesAllowed("witek") but without security-constraint I get javax.ejb.AccessLocalException: Client not authorized for this invocation.
I`m using glassfish 5 and netbeans.
Rest of the steps I made:
1. I made my own realm and user through gl console.
2. I made user to group mapping in glassfish-web.xml
3. My web.xml :

Code: Select all

<security-constraint>
    <web-resource-collection>
      <web-resource-name>test</web-resource-name>
      <url-pattern>/*</url-pattern>   
    </web-resource-collection>
    <auth-constraint>
      <role-name>witek</role-name>
    </auth-constraint>   
  </security-constraint>
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>realmyInny1</realm-name>
  </login-config> 
  <security-role>
    <role-name>witek</role-name>
  </security-role>
It works in this configuration, but without <security-constraint> section it doesn't work.
Could somene be so kind and explain mi why?

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Mon Jun 11, 2018 11:35 pm
by fjwalraven
Hi!

I am not sure why you want to do it without a security constraint? Have you read the Java EE6 tutorial about security?

https://docs.oracle.com/javaee/6/tutori ... gijrp.html

Regards,
Frits

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Tue Jun 12, 2018 2:08 pm
by witek_m
Thank you, I read most of it. Maybe I missunderstood option: "Add a security constraint in the web deployment descriptor to restrict certain URL's." -> so I have to use security constraint but not to restrict certain URL`s.
I have two questions connected with it, maybe someone could help me with it:

1: I tryed in analogue way securing webservice - in the same application as first example I made @Stateless class with @Webservice annotation and method with @RollesAllowed annotation, but It desn`t work - I can view wsdl without user login and I can`t invoke webservice method. When I try I get :
JACC Policy Provider: Failed Permission Check, context(Naukaweb/Naukaweb_internal)- permission(("javax.security.jacc.EJBMethodPermission" "NewWebService" "hello,ServiceEndpoint,java.lang.String"))

2: Im not sure when I have to use @DeclaresRoles annotation.

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Tue Jun 12, 2018 2:36 pm
by fjwalraven
I can view wsdl without user login and I can`t invoke webservice method
This means that your user doesn't have the correct role.
2: Im not sure when I have to use @DeclaresRoles annotation.
The @DeclareRoles annotation is used to declare the security role names used in the enterprise bean code. The deployment descriptor equivalent is the <security-role> element.

You might want to go through my ejb notes (security part)
https://coderanch.com/wiki/659897/OCEEJBD-Links

Regards,
Frits

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Wed Jun 13, 2018 12:09 pm
by witek_m
1. I checked my login user by using injected WebServiceContext: WebServiceContext.getUserPrincipal().getName() -> ANONYMOUS
2. I see, thank you.

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Wed Jun 13, 2018 1:21 pm
by fjwalraven
I checked my login user by using injected WebServiceContext: WebServiceContext.getUserPrincipal().getName() -> ANONYMOUS
This indicates that the user is not authenticated. Try creating a simple jsp with a login page, enforce authentication, and invoke the Webservice from the Servlet that is behind the login page. You will see that the credentials are propagated from the Servlet-container to the EJB-container.

Re: About Question enthuware.ocejws.v6.2.226 :

Posted: Mon Feb 25, 2019 2:58 am
by NellieCunningham
thank you for sharing information and your experience guys it was very much helpful to understand many other things rather then just understanding our issues.