First of all, can we at least agree on the following:
1. Not everyone uses JAAS, or even wants to use JAAS
2. Numerous alternative OSS security frameworks exist (eg http://www.manageability.org/blog/stuff/single-sign-on-in-java/view)
3. Real-world applications see a huge variety of security approaches including (a) home-grown approaches, (b) alternative OSS frameworks, and (c) JAAS (probably in that order)
4. Often alternative OSS security frameworks and home-grown approaches cannot easily be made integrate into a JAAS LoginModule
As someone who administers an OSS security framework project, and have a good deal of familiarity with JAAS, I know the above four points are very much the case. I should also mention that I have no ideological objection to JAAS, as demonstrated by the fact our security framework offers direct JAAS and application server realm integration.
Stefan Guggisberg wrote:
what you're saying is if someone wants to adapt Jackrabbit to their ownThe numerous people out there using an OSS security framework, or a home-grown approach, that would not hesitate or mind implementing the interface I suggested. After all, it's only a couple of methods and means they (a) need not replace their entire security infrastructure or (b) reengineer their security framework to be "JAAS compatible". For the JAAS users out there, they will be more than effectively served by the default implementation of the interface that ships with Jackrabbit. They would not notice nor care about the fact that this extra interface exists between Jackrabbit and the JAAS layer.
authentication scheme, they are going to have to create a yet-another-authentication-api adapter/implementation?
i can't see anything wrong in jackrabbit using JAAS APIsLet me try to answer that. As mentioned above, many people do not want to use JAAS. A significant proportion of today's applications use non-JAAS security approaches, and some approaches cannot technically support JAAS even if they wanted to. Even if JAAS support is theoretically possible for these frameworks, it's a lot of work making them operate properly within JAAS - especially compared with implementing a simple interface such as I proposed in the earlier post. You also have to ask why these security frameworks have achieved momentum in the first place, if JAAS was so attractive to all people and all situations.
why reinvent our own? you will always have to write an adapaterAt an OO design level, the golden objective is high cohesion and loose coupling. The proposed interface represents the subset of authentication capabilities that Jackrabbit actually needs. Using a simplified abstraction interface achieves the goal of high cohesion and loose coupling, whereas hard-coding JAAS references represents low cohesion (Jackrabbit doesn't need everything JAAS offers) and tight coupling (non-JAAS approaches that could easily meet Jackrabbit's authentication requirements cannot be used). Sound OO is reflected by the JSR 170 specification itself which does NOT mandate JAAS.
if you want to use your own custom authentication scheme.
i don't a see a benefit in implementing something like AuthenticationToken as ben suggested compared to LoginModule.
I hope the above has provided some additional context and the Jackrabbit community will be supportive of a security abstraction interface. If not, I suppose I have three questions it would be interesting to receive some feedback on:
1. How does Jackrabbit justify JAAS as the sole security framework, when both the JSR 170 specification and implementation reality reflect otherwise?
2. At a conceptual OO level, what is wrong with a security abstraction interface that allows people to use the numerous non-JAAS frameworks frequently deployed in the real world?
3. How is it enhancing Jackrabbit adoption by alienating all the users of home-grown and non-JAAS security frameworks?
Best regards Ben
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
