Page 1 of 1
About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Sat Aug 17, 2013 7:35 am
by mopuffus
Hi
I think that the answer
Bean provider declares the logical security roles used in the application.
suggested as correct is wrong.
Here is my argumentation:
- 1. The Bean Provider can define security role references (security-role-ref). The security role references are for the component (not for the application). The security role references can be linked to security roles but this can be done by the Application Assembler - because this role has information about the application logic.
2. The Application Assembler is the role has the most knowledge about the business logic -> he/she is the one that defines application (logic roles).
Under this argumentation I don't think that the upper quoted statement is correct.
IMHO the correct answer can be :
Bean provider declares the logical security roles
references used in the
component.
or
Application Assembler declares the logical security roles used in the application.
Best Regards,
Mihai
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Sat Aug 17, 2013 6:26 pm
by admin
I think you are right the but the wording used by the specification in Section 17.1 is "security role" and not "security role ref".
To make the Deployer’s task easier, the Bean Provider or the Application Assembler (which could be the same party as the Bean Provider) may define security roles for an application composed of one or more enterprise beans.
HTH,
Paul.
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Wed Aug 21, 2013 11:02 am
by mopuffus
Dear Paul,
Thanks for your answer specially for the specification quote.
On the other side I think that we deal with a semantic overloading for the term "security role".
IMHO the involved question (enthuware.oce-ejbd.v6.2.573) refers the
security role where the bean provider can be involved (more precisely the security role references). In your extract from the specification the "security role" term is used in a more generic way and I think that it may include the
security role and the
security role references.
Later in the specification (17.3) you can find the following:
The Bean Provider and Application Assembler (which could be the same party as the Bean Provider) may define a security view of the enterprise beans contained in the ejb-jar file.
and
The security view consists of a set of security roles. A security role is a semantic grouping of permissions that a given type of users of an application must have in order to successfully use the application.
Even if in the real life situation the bean provider is the same person like the application assembler there are still two distinct roles. Under this circumstances (and IMHO) you can not provide application scoped security scoped if you are just bean provider. You will need both roles to accomplish this.
What do you think ?
Best Regards,
Mihai
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Sun Aug 25, 2013 10:36 am
by admin
Hi,
Yes, what you are saying is correct. However, the bean provider does actually create "logical security roles". These are only "logical" roles that he thinks makes sense for his code. He declares references to these roles and not to the actual roles. Even the name of the annotation for this is @RolesAllowed or @DeclareRoles (not RoleRef)
The application assembler defines the actual roles that make sense for the application (and not just for a particular bean). He also maps these actual roles to the logical roles used by the bean provider.
This is the same terminology i.e. "logical roles" used by the specification in Section 17.3.1 as well.
HTH,
Paul.
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Sat Jan 17, 2015 1:36 pm
by garfield
Option 5 "Application assembler declares roles used in the beans using the security-role-ref elements." could be also correct.
As of section 17.3.3 Linking Security Role References to Security Roles which could be resposibility of Bean Provider or the Application Assembler.
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Tue Jun 02, 2015 10:38 am
by himaiMinh
I think option 5 is possible because application assembler may be able to use <security-role-ref> to override/augment security roles which have been defined using annotation by the bean provider.
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Mon Jan 04, 2016 4:00 pm
by aazizi.tarik
You said :
The application assembler defines the actual roles that make sense for the application (and not just for a particular bean). He also maps these actual roles to the logical roles used by the bean provider.
in order to map the actual roles to the logical roles used by the bean provider you must use security-role-ref elements. Which is in contrast with option 5 explanation: "Bean provider does this." !
So I think, its the Application assembler who use security-role-ref elements, but for mapping roles and not declaring them.
I have made a small picture to summrize that, your ramarks are welcome:
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Tue Jan 05, 2016 9:02 pm
by admin
Right, application assembler maps the logical roles to real roles.
Bean provider declares the logical security roles used in the application.
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Fri Jan 08, 2016 3:29 pm
by aazizi.tarik
I still think that this:
Bean Provider does it using annotations @RolesAllowed and @DeclareRoles and Application assembler does it using <security-role> elements.
is contradictory with the option 5! don't you think so ?
Re: About Question enthuware.oce-ejbd.v6.2.573 :
Posted: Sun Jan 10, 2016 8:42 am
by admin
I don't see any contradiction.
1. The application assembler cannot do it using @RolesAllowed and @DeclareRoles because he doesn't have access to the source code of the beans.
2. Application assembler cannot declare roles used in the bean because he doesn't know what roles the bean provider has used. It is the bean provider who have to given that information. The application assembler can them map them to the real roles using <security-role> element.
HTH,
Paul.