Thread: [smartweb-devel] Requirements for auth module
Brought to you by:
rlogiacco
Menu
▾
▴
smartweb-devel
|
From: rlogiacco <rlo...@us...> - 2007-04-03 13:32:40
|
It may sound rough, but actually the most important module of the framework is no more working! We should solve this big problem urgently and give it back to the community for upgrades, improvements but mostly for usage!!! Actually the problem was introduced because a major update started a few months ago, but I have to admit I committed a big mistake not branching before starting to work to the next generation module. Personally I think now is too late to fall back 'cause we are pretty near to the end. For the future and for every module coordinator I strongly suggest to branch before starting a new implementation: you can work without feeling your users' breath over your neck... ;) Anyway, returning to the topic, I'm here to define the requisites of the module to share and clarify them once and for all. 1. users and groups should be threated in a similar manner being interchangeable; 2. the administrator must be able to tell the module "allow user/group X to operate in the role Y only if the function operates on object of type Z and id N [ and current time is between 8am and 6pm ]" with the last part optional and customizable; 3. permissions and rules should be customizable through a configuration file without intervention into the code, allowing a method level granularity similarly to the EJB security constraints; 4. users are stored by default on database, but other sources for datas (LDAP for example) should be configurable; 5. no constraints between the auth module datas and other modules to allow deployment on separate databases; 6. no class constraints and no requirements on the classes using the module: as stated before the security constraint should be activatable at configuration time (AOP should be the solution); 7. customizability both of authentication process and authorization process like "no logins for users in role X between 8pm and 8am" or "disallow requests to function F if more than 5 users already logged" through custom classes and configuration; 8. ability to load balance the module with the web application; 9. ability to check credentials both on presentation tier "show this field only if user is authorized" and on business tier "allow this operation only if user is authorized" 10. support for distributed presentation and business tiers (on two or more servers) and implicit transmission of credentials (needs integration with JAAS) Have I forgot something? Roberto -- View this message in context: http://www.nabble.com/Requirements-for-auth-module-tf3513039s17546.html#a9810970 Sent from the SmartWeb Developers mailing list archive at Nabble.com. |
|
From: rlogiacco <rlo...@us...> - 2007-05-11 11:39:04
|
rlogiacco wrote: > > 1. users and groups should be threated in a similar manner being > interchangeable; > 2. the administrator must be able to tell the module "allow user/group X > to operate in the role Y only if the function operates on object of type Z > and id N [ and current time is between 8am and 6pm ]" with the last part > optional and customizable; > 3. permissions and rules should be customizable through a configuration > file without intervention into the code, allowing a method level > granularity similarly to the EJB security constraints; > 4. users are stored by default on database, but other sources for datas > (LDAP for example) should be configurable; > 5. no constraints between the auth module datas and other modules to allow > deployment on separate databases; > 6. no class constraints and no requirements on the classes using the > module: as stated before the security constraint should be activatable at > configuration time (AOP should be the solution); > 7. customizability both of authentication process and authorization > process like "no logins for users in role X between 8pm and 8am" or > "disallow requests to function F if more than 5 users already logged" > through custom classes and configuration; > 8. ability to load balance the module with the web application; > 9. ability to check credentials both on presentation tier "show this field > only if user is authorized" and on business tier "allow this operation > only if user is authorized" > 10. support for distributed presentation and business tiers (on two or > more servers) and implicit transmission of credentials (needs integration > with JAAS) > > Have I forgot something? > Yes, I forgot to mention the anonymous user: we should define a constant referencing the non authenticated users, also known as guest or anonymous. With this constant we can easily avoid NullPointerExceptions and uncessary code branchings I think. If you get any ideas, please submit them! -- View this message in context: http://www.nabble.com/Requirements-for-auth-module-tf3513039s17546.html#a10430270 Sent from the SmartWeb Developers mailing list archive at Nabble.com. |
|
From: amarini <ann...@gm...> - 2007-06-22 18:30:00
|
On purpose of authorizations=E2=80=A6 My idea on the management of the authorizations is that the structure must be the much simple one, easy performing and understanding but at the same time useful, highly flexible and untied from the platform.=20 For this reason, the entities I think to, reflect the greater problems but at the same time the most common reality.=20 A user, assimilating to others, can approach something, often leaked and ca= n manage it to a defined level: user, group, role, property, permission.=20 All without subordination of an entity to one another: a user can be in relation to one or more groups but can also be free and vice versa; both ca= n have one or more roles to which grant permissions in order to manage the access to the functionalities (where to navigate, what to visualize, how to interact) and both can have property in order to manage the tracing of the data (which geographic, economic, temporal contents=E2=80=A6). Annamaria --=20 View this message in context: http://www.nabble.com/Requirements-for-auth-m= odule-tf3513039s17546.html#a11257671 Sent from the SmartWeb Developers mailing list archive at Nabble.com. |
|
From: rlogiacco <rlo...@us...> - 2007-06-22 20:29:48
|
amarini wrote: >=20 > My idea on the management of the authorizations is that the structure mus= t > be the much simple one, easy performing and understanding but at the same > time useful, highly flexible and untied from the platform. >=20 We share the same vision :-) amarini wrote: >=20 > A user, assimilating to others, can approach something, often leaked and > can manage it to a defined level: user, group, role, property, permission= .=20 > All without subordination of an entity to one another: a user can be in > relation to one or more groups but can also be free and vice versa; both > can have one or more roles to which grant permissions in order to manage > the access to the functionalities (where to navigate, what to visualize, > how to interact) and both can have property in order to manage the tracin= g > of the data (which geographic, economic, temporal contents=E2=80=A6). >=20 Actually you depicted 90% of the smartweb auth module, but you added something: a new perspective to the problem which I would better investigate. I think you are proposing to resolve the scope and function problems with a standard parameters map through which associate properties to roles and users... It could be a simple solution to the big problem: what about helping us to analyze the idea? I think a little bit of documentation can help: an ER or class diagram should do the trick to clarify the idea. I think applying the AOP paradigm to the Jakarta Struts Taglib we can easil= y use the properties map to simplify the JSP development... more I think abou= t it and more I like your suggestion! Can you provide a diagram of some sort? --=20 View this message in context: http://www.nabble.com/Requirements-for-auth-m= odule-tf3513039s17546.html#a11259530 Sent from the SmartWeb Developers mailing list archive at Nabble.com. |
|
From: amarini <ann...@gm...> - 2007-06-28 09:19:10
|
Here the diagram=E2=80=A6 I identify a subject to which I tie some features, to bridge possible external structures, to allow for example a registry identification or to describe subject=E2=80=99s qualities, etc....=20 The user and/or the group complete the authentication of a subject, while, the pertinent authorizations are declared from scopes and privileges (the last ones, directly tied to the role). The scopes define the requisite properties to specify the limit of action for the tracing of the data while the privileges establish the allowed functionalities for the attributed role. I=E2=80=99ll wait your remark=E2=80=A6 http://www.nabble.com/file/p11339787/er1.clay er1.clay=20 --=20 View this message in context: http://www.nabble.com/Requirements-for-auth-m= odule-tf3513039s17546.html#a11339787 Sent from the SmartWeb Developers mailing list archive at Nabble.com. |
|
From: amarini <ann...@gm...> - 2007-07-05 12:03:10
|
Here is a short document that would be the exposition of my previous er diagram... Let me know if you need more extending. Thank's AUTHORIZATIONS The module for authorizations management has a much simple structure. It must come out easy performing and understanding but at the same time it must be useful, highly flexible such to produce it untied from the chosen platform for the applications development. For this reason, the entities reflect the greater problems but at the same time the most common reality. The module resolves both authentication and permissions. AUTHENTICATION The authentication occurs through the ascription of an user and/or a group to a subject. Defined features belong to the subject and they allow to bridge possible external structures in order to couple the useful information to the regular management of the authentication of the subject. PERMISSIONS The permissions are declared through their grant to a subject. They are composed from the definition of the scopes and from the privileges that belongs to the specific roles of the subject. The scopes define necessary properties to specify the limit of action for the tracing of the data and they are directly tied to permissions. The privileges establish the allowed functionalities for the role attributed to the subject and they are directly tied to roles. -- View this message in context: http://www.nabble.com/Requirements-for-auth-module-tf3513039s17546.html#a11445153 Sent from the SmartWeb Developers mailing list archive at Nabble.com. |
|
From: rlogiacco <rlo...@us...> - 2007-07-31 13:23:31
|
Other requirements I've missed are: #. do not store clear password, instead store an hash of the password and on login check the providen password produces the same hash; #. add a new status to mark users who MUST change their password on logon (usefull for many actions); #. add "password forgotten" functionality which must generate a new password, replace the old one and allow the caller to notify the new password to the user (by email, on screen, by SMS or any other communication channel you can think of). rlogiacco wrote: > > Anyway, returning to the topic, I'm here to define the requisites of the > module to share and clarify them once and for all. > > 1. users and groups should be threated in a similar manner being > interchangeable; > 2. the administrator must be able to tell the module "allow user/group X > to operate in the role Y only if the function operates on object of type Z > and id N [ and current time is between 8am and 6pm ]" with the last part > optional and customizable; > 3. permissions and rules should be customizable through a configuration > file without intervention into the code, allowing a method level > granularity similarly to the EJB security constraints; > 4. users are stored by default on database, but other sources for datas > (LDAP for example) should be configurable; > 5. no constraints between the auth module datas and other modules to allow > deployment on separate databases; > 6. no class constraints and no requirements on the classes using the > module: as stated before the security constraint should be activatable at > configuration time (AOP should be the solution); > 7. customizability both of authentication process and authorization > process like "no logins for users in role X between 8pm and 8am" or > "disallow requests to function F if more than 5 users already logged" > through custom classes and configuration; > 8. ability to load balance the module with the web application; > 9. ability to check credentials both on presentation tier "show this field > only if user is authorized" and on business tier "allow this operation > only if user is authorized" > 10. support for distributed presentation and business tiers (on two or > more servers) and implicit transmission of credentials (needs integration > with JAAS) > > Have I forgot something? > > Roberto > -- View this message in context: http://www.nabble.com/Requirements-for-auth-module-tf3513039s17546.html#a11923937 Sent from the SmartWeb Developers mailing list archive at Nabble.com. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X