Hi,
Here are my initial set of comments/questions for the EDR1 review based on
the current doc so far. Will continue to review. Thanks for all who have
worked on this.
1) Authentication Mechanism:
a) When the auth-method is set to AUTHMECH and the application does not
provide its own HttpAuthenticationMechanism what is the expected behavior?
Depends on the container (if it provides a system one or not)?
b) The HttpMessageContext description is missing in the doc.
c) What is the difference in the expected behavior when the validate
returns INVALID vs NOT_VALIDATED? Container dependent or anything that spec
needs to address? Believe INVALID should be resulting in some re-login
attempt but NOT_VALIDATED would have to throw an exception.
2) Identity Store:
a) Since there is no authorization being performed by the identity store
itself may be use AuthorizationInfo or UserGroups or something similar -
as pointed out in the review comment.
b) As the review comment suggests, Set would be more appropriate when
returning the groups for both methods.
c) For the issue with callerPrincipal not being unique when getting groups,
the unique identifier approach makes sense.
d) The simple way to protect the getGroups call is to use a Java 2
permission (when security manager is enabled) but very few folks enable
Java 2 security.
e) The configuration to make the build-it beans available is something
specific to the containers/servers - i.e outside of the specification?
f) Given the concern for Embedded IdentityStore, may be we can make just
the LDAP IdentityStore as required and others optional for containers to
implement since anyone can implement their own specific IdentityStore?
g) For the LDAP IdentityStore annotations, one approach could be to use the
LDAP filter format when searching the users/groups -something like
(&(objectClass=person)(objectClass=user))? Wanted to get some thoughts on
this.
Some examples:
userFilter="(&(uid=%v)(objectclass=person))" // to search for the user
using the uid attribute in person ObjectClass.
groupMemberFilter ="groupOfNames:member;groupOfUniqueNames:uniqueMember" //
to search for groups for the user using the member and uniqueMember
attributes in the groupOfNames and groupOfUniqueNames objectclasses
respectively.
These would be similar to callerQuery/groupsQuery in the database
annotation.
Also, given the fact that a user is represented in multiple ways in LDAP
and can log-in using different formats (bob - bob_at_myCompany.com - cn=Bob
Smith,ou=myCompany,o=us) we need a consistent way to return for the
programmatic APIs like getUserPrincipal, getRemoteUser,
getCallerPrincipal,(bob which is the uid - for eg). This might require
another filter to get that information.
For example (use the uid attribute from the objectClass person)
userIdMap="person:uid"
These filters can be directly passed to the LDAP servers during search and
are flexible enough to handle any attribute that one wants to use. This
would also reduce the # of methods.
Should authenticateOnly and authorizeOnly be just authenticate and
authorize/authorizeInfo/userGroups?
Should baseDN be bindDN?
3) Security Context
Not sure how much of the Security Context will be supported in this JSR
given the resource/time issues that have been mentioned. The api-sec
includes more methods than listed in the current doc. For example,
a) getAllDeclaredCallerRoles - Expected to return all the assigned roles
for the caller principal (directly and indirectly through groups) in the
authorization configuration? If so, since the role to user/group mapping is
at the application level, this can include additional roles that may not be
relevant to this web resource - or some kind of filtering is expected?
b) hasAccess* - what web resources are these? Same app only or any web app
in the container? What are the typical use cases for this?
Will have to investigate these more but wanted to understand the usage/use
cases first.
Thanks for your time.
Regards,
Ajay Reddy