Hi Sune, > Kalle, if I am understanding you correctly, there is no “total package” for > a security solution (meaning API and underlying implementation for both > managing and applying security features)? – and the reason or this is, that > in most cases when you need to apply security to your application, you > already have an existing user database (and then you just extend it with > roles and permissions as needed – by hand). >
Its not that they're existing only. Applications might want to store this data in a new data source, which might be LDAP or RDBMS-based, or some proprietary back-end entirely. > But is this what everybody does when they need to apply role-based > permissions to a system – code it from scratch (everything from designing > database tables to making a UI within your application, that allows the > administrators to manage these settings)? > Yep, that's pretty much what everyone does - the data model format, entity relationships and GUIs are all _very_ specific to the application or company or both. > Of course I see the problem in making an API, that adapts to all the > various ways these data can be stored, but in some (most?) situations you > don’t have to that much to apply the security (i.e. read from the model) – > you only have to do some configuration, right? …or do you need to extend one > of the existing realms to make it understand exactly how your data model is > wired? > It depends - applications with simpler data modes can use many of the existing realm implementations out of the box. However, medium to complex applications often require subclassing for custom logic. > If only configuration is needed, then my next question would be: Couldn’t > you just make an implementation for managing permissions, that used the same > configuration to figure out how to write to the tables? …or is it more > complicated than that? (I’m just talking about making an API available for > managing this – not an entire UI application) > It depends on the Realm. For example, the JdbcRealm assumes a particular table structure, but you can of course override the select statements to match your tables. The same would have to happen for update statements. So yes, this is configurable to a degree, but it is still heavily realm-dependent. > I learned that Spring Security specifies how to design the data model, when > you want to use ACL – how come they do that? Is that because ACL is so > freaky, that it needs to be implemented in a certain way (and most likely * > *not** part of the existing user tables you got) or am I getting it all > wrong? > Jeremy answered this, but I'll add that perhaps having an interface-based (but still optional) API would probably be very useful to helping people understand a 'best practices' data model. You might want to open a Jira issue to ask for this - it usually won't get done unless its in Jira :) > I hope you won’t forget my question from my previous mail about having to > apply security to an application where part of it has a session with a > logged in user, and part of it is stateless and requires all information to > be included in the invocation… > What information are you talking about exactly? Ki's default mechanisms usually append a session ID as payload to a remote method invocation. This session id is attributed to a session on the back end, which contains identity information enough such that a Subject can be associated with the request/method invocation and appropriate checks can be done during that request/MI. Regards, Les
