Comparing Domino's security and EJB is definitely comparing apples and oranges. However in reality this is what you have to do on a daily basis. There are similarities and differences. Let us have a look at the scope: I will look at Domino server security rather than Notes client security, therefore I won't consider: encryption, signatures or access controlled sections. The biggest difference: Domino is a monolithic product that handles all aspects from authentication to authorisation to database security. EJB is a specification where security covers what happens inside an EJB container. This specification has been implemented by various vendors (IBM, Bea, JBoss, Sun, Oracle, Apache Jeronimo etc.), so you have a blend of implemented specifications and the vendor's part that continues where the specs end.
When you setup Domino, well you setup Domino. It will take care of database, application and presentation. While this seems straight forward it can be tricky too. What it lacks are choices, you do it the Domino way period. With every version Domino has opened up and as of now you can use an LDAP for authenticating your users.
When you setup an EJB container, the most obvious difference are the choices you have (to make): what container to use, how to authenticate users, what database(s) to use and so on. Since the EJB specs don't talk about authentication it is the EJB container manufacturer's choice how to implement that, therefore that's out of our scope.

Security in Domino
At the core of Domino security is data security on the document level. While this is not fully accurate, you can say Domino defines security on a database record level. Every "record" has two special fields: Reader and Authors. This is a logical view on how it works, these fields do not physically exist in a record (in Domino it's documents anyway) but are the sum of all fields in a document with the respective data types. The fields can have 0 to n entries each (so in a relational database you would have two auxiliary tables tblReaders, tblAuthors). This fields can contain: Roles, Groups or Individual names. The fields support X500 canonical names. The very moment the reader field has one entry the document is visible ONLY to users (and servers) that are matched by the Reader field content. Even if you are the database administrator: if you are not matched in the reader field (or author field, see below) you won't see the document. I haven't come across an other database that protects its data such flexible on a row level, build into the product as standard mechanism.
The functionality provided by the author field is quite similar. You need to be listed (explicit or implicit) in the author field to be considered an allowable author of this document. The main difference here: if your database access is "Reader", you won't be able to edit any document, thus no point being an "allowable author". Your status as an allowable author includes read access, so you don't need to be listed in both fields. Once you access is "Editor" (or higher) then you can edit any document regardless of your membership in the Authors field. Of course you can't edit a document you can't see. So the default access setting for authorized users should be "Authors" (At least that is my preaching in Domino classes). Properly designed databases are that way.
Which brings us to the second level of security: the ACL. Every single database has one. Here you define the access rights (for details see the Domino help). The ACL defines access level, role names and role memberships. The ACL is also the interface between the developer and the administrator. So your security chain has two roles involved:



This is also the point where Domino security is very powerful and a bit muddy. The declarative security in Author and Reader fields works with roles, groups and individuals. So any change in the structure of your directory might directly affect the data contained in your applications, given you (hard)coded group names. Careful planning and proper setup of  server processes (adminp) help to avoid data disasters. I came across quite a number of applications that needed major refactoring to handle that properly. As a rule of thumb: try to stick with roles rather groups unless you have a good reason. Beyond the ACL there are server security setting who can execute what code and access servers at all. While this pieces are important for a secure application, they don't impact this comparison.

Security in EJB
Security in EJB follows a very different principle. There is no data(base) security -- this is handled by the database OUTSIDE the EJB container; there is no authentication -- this is handled OUTSIDE the EJB container. EJB security focus around execution. You can define for each and every method of each and every Enterprise Bean who can execute it.  Since one method either reads or writes (think getLastName/setLastName) you effectively have effective control what field can be read and written by an user. However the "who" is limited to roles, not group memberships or individuals. Since this adds a lot of decisions and configuration requirements, the security process involves more roles than in Domino.



The developer can use the functions "getPrincipal" or "isInRole" to figure out access levels inside his code. He has no access defined in EJB to group memberships. If that should be used, vendor specific code is needed that might hurt portability. The red on grey text represents the parts that are defined in EJB. The blue on yellow represents vendor specific implementations.
The execution permissions mentioned before are mapped by the application assembler outside the Java code to an abstract role name in the deployment descriptor. So two roles define security: the application assembler in regards to who (=which ROLE) can call what method and the developer for security in code logic. The application deployer (who is part of the admin team) maps the abstract role name to an actual role in the system. This way name conflicts in different applications for sure can be avoided. The distribution of security responsibilities over more roles reflects the usual larger scale of EJB projects, where skill requirements are much more diverse and it is likely that its reasonable that a developer doesn't need to care about security.
The main difference to Domino is the focused on the Bean CLASS not the bean object instance. In Domino the form serves as a blueprint for the items (fields) in a document, which can be altered by code. The fields determine the access to every single instance (document). In EJB the access is defined by the class rather the instance. Instance specific security needs to be coded and this is not defined in the EJB spec.

In summary
You see the questions "which is better" can't be answered. Domino's document level security is unique and valuable. EJB can talk to Domino, so have a close look and make your pick (it doesn't need to be either or).

No documents found