taylor 02/05/23 17:07:00
Modified: proposals Security.txt
Log:
updated the proposal. Still have a few more issues to work out tonight.
Will submit rev.01 to the list tonight...
Revision Changes Path
1.2 +213 -109 jakarta-jetspeed/proposals/Security.txt
Index: Security.txt
===================================================================
RCS file: /home/cvs/jakarta-jetspeed/proposals/Security.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Security.txt 23 May 2002 06:40:13 -0000 1.1
+++ Security.txt 24 May 2002 00:07:00 -0000 1.2
@@ -1,5 +1,5 @@
Jetspeed Proposal: Portal Security 1.4
-LAST MODIFIED: $Date: 2002/05/23 06:40:13 $
+LAST MODIFIED: $Date: 2002/05/24 00:07:00 $
AUTHOR: [EMAIL PROTECTED], [EMAIL PROTECTED]
STATUS:
@@ -96,6 +96,7 @@
3. Authorization
4. Security Entity Maintenance
+
See section 3 below for details
-------------------------------------------------------------------------------------------------------
@@ -120,13 +121,33 @@
Jetspeed's current security service extends it:
org.apache.jetspeed.services.JetspeedSecurity
+-----------------
+2.1 Permissions
+-----------------
+The Turbine Permission class will not be used in the interfaces.
+Permissions can be checked with the Jetspeed Security API
+
+-----------------
+2.2 Access Control
+-----------------
+The Turbine AccessControl class will not be used in the interfaces.
+Permissions can be checked with the Jetspeed Security API
+
-------------------------------------------------------------------------------------------------------
-(3) Specification for Portal Security
+(3) Specification for Portal Security Implementor
-------------------------------------------------------------------------------------------------------
---------
-3.1 User
----------
+-------------------
+3.1 Security Model
+-------------------
+
+In sections 3.1.x, the security model objects are described.
+The security service implementor must support the interfaces and concepts when used
in any of the four sets
+of service interfaces described in section 3.4
+
+-----------
+3.1.1 User
+-----------
The org.apache.turbine.om.security.User interface will be difficult to replace,
since it is used
throughout Turbine, and Jetspeed is still highly dependent on Turbine. For example,
the User interface is coupled
to RunData interface, which is ubiquitous both in Turbine and Jetspeed. For these
reasons, its
@@ -141,39 +162,32 @@
boolean getDisabled();
void setDisabled(boolean disabled);
-}
+ String getUserId();
+}
-----------------
-3.2 Permissions
+3.1.2 Groups
-----------------
-The Turbine Permission class will not be used in the interfaces.
-Permissions can be checked with the Jetspeed Security API
+Per several requests, Groups are back in the spec.
+Groups are represented as a String.
------------------
-3.3 Access Control
------------------
-The Turbine AccessControl class will not be used in the interfaces.
-Permissions can be checked with the Jetspeed Security API
+Definition:
+
+An abstract logical grouping of Jetspeed users.
-----------------
-3.4 Groups
+3.1.3 Roles
-----------------
-Groups, as a security element, will be dropped from Jetspeed 1.4
-Groups are only valid in a profile locator in the default Jetspeed profiler.
-In order to provide security to a group profile, simply place a security constraint
on the root portlet set of that resource.
-As a security element, it would be useful to have groups of users that can be
assigned roles.
-This feature is tabled for a future rev.
+Roles are represented as a String.
------------------
-3.5 Roles
------------------
+Definition:
-Same as Turbine's, different om package.
+An abstract logical grouping of Jetspeed users.
---------------------------
-3.6 Conformancy
+3.3 Conformancy
---------------------------
The security interfaces are grouped by:
@@ -200,10 +214,6 @@
If your service does not provide a requested method, a <TBD> exception will be
thrown.
-
------------------------------------------
-3.6 The Default Implementation
-------------------------------------------
The default implementation will conform to all levels.
If you have an authentication server, and only want to implement the authentication
interfaces with your server, you can
@@ -211,84 +221,101 @@
Likewise, delegating to the default implementation where necessary is allowed, and
disabling of the default implementation for
any optional interfaces. Required interfaces may not be disabled.
+--------------------------------
+3.4 Security Service Interfaces
+---------------------------------
----------------------------
-3.8 Authentication (Required)
----------------------------
+
+------------------------------
+3.4.1 Authentication (Required)
+------------------------------
+
+Defines the contract between the portal and security provider required for
authentication a Jetspeed User.
interface PortalAuthentication
{
- login( String username, String password );
- login( Principal principal );
- boolean accountExists( String username );
+ User login( String username, String password );
+ User login( Principal principal );
+ User getAnonymousUser();
}
-------------------------------------
-3.9 Credentials and User Management (Optional)
-------------------------------------
+-----------------------------------------------
+3.4.2 User Management (Optional)
+-----------------------------------------------
+
+Defines the contract between the portal and security provider required for managing
users.
interface UserManagement
{
User getUser( String username );
- Iterator getUsers( Criteria criteria );
-
- User getAnonymousUser();
+ Iterator getUsers( String filter );
- void saveUser( User requestor, JetspeedUser user );
+ void saveUser( User user );
- void addUser( User requestor, User user ) ;
+ void addUser( User user ) ;
- void removeUser( User requestor, User user );
+ void removeUser( User user );
- grantRole(User requestor, User user, Role role);
+ grantRole(String username, String role);
- revokeRole(User requestor, User user, Role role);
+ revokeRole(User user, String role);
}
+-----------------------------------------------
+3.4.3 Credentials (Optional)
+-----------------------------------------------
+
+Defines the contract between the portal and security provider required for managing
credentials.
+
interface CredentialManagement
{
- void changePassword( User requestor,
- User user,
+ void changePassword( String username,
String oldPassword,
String newPassword )
- void forcePassword( User requestor, User user, String password );
+ void forcePassword( String username, String password );
}
------------------------------------
-3.10 Authorization (Required)
+3.4.4 Authorization (Required)
------------------------------------
interface PortalAccessController
{
boolean checkPermission(User user, Entry entry, String action);
boolean checkPermission(User user, Portlet portlet, String action);
+
+ boolean checkPermission(User user, String resource, String action);
+
+ boolean checkPermission(User user, Permission permission, String action);
}
-------------------------------------
-3.11 Security Entity Maintenance (optional)
-------------------------------------
+--------------------------------------------
+3.4.5 Security Entity Maintenance (optional)
+--------------------------------------------
+
+***** This section is under construction (3.4.5) DST
interface RoleManagement
{
- Role getRole( User user, String name );
+>>>> remove >>> String getRole( User user, String name );
Iterator getRoles( User user );
Iterator getRoles();
- void saveRole(User requestor, Role role );
- Role addRole(User requestor, Role role );
- void removeRole(User requestor, Role role );
+ void saveRole( Role role );
+ Role addRole( Role role );
+ void removeRole(Role role );
}
interface SecurityActionManagement
{
- SecurityAction getSecurityAction( User user, String name );
- Iterator getSecurityActions( User user );
+>>>> remove >>> String getSecurityAction( User user, String name );
+>>> remove >>>> Iterator getSecurityActions( User user );
Iterator getSecurityActions();
- void saveSecurityAction(User requestor, SecurityAction action );
- SecurityAction addSecurityAction(User requestor, SecurityAction actoin );
- void removeSecurityAction(User requestor, SecurityAction action );
+>>>> remove >>> void saveSecurityAction(User requestor, String action );
+>>>> remove >>> String addSecurityAction(User requestor, String action );
+>>>> remove >>> void removeSecurityAction(User requestor, String action );
}
// In the default implementation constraints are stored in the security registry
@@ -306,11 +333,15 @@
-------------------------------------------------------------------------------------------------------
-(4) Deployment -- Security Tags in Registry and PSML
+(4) Deployment -- Jetspeed Security Tags in Registry and PSML
-------------------------------------------------------------------------------------------------------
-In Jetspeed 1.3, security access to portlets and portlet instances is controlled
via the registry and
-PSML files respectively. In the registry, this is accomplished with a security
element and a single role
+---------------------------------------
+4.1 Jetspeed 1.3 Security Descriptors
+---------------------------------------
+
+In Jetspeed 1.3, security access to portlets and portlet instances is controlled
via the registry and
+PSML files respectively. In the registry, this was accomplished with a security
element and a single role
attribute:
<portlet-entry �>
@@ -318,7 +349,7 @@
�
-In PSML, it is similar yet multiple rows are allowed:
+In PSML, it is similar yet multiple roles are allowed:
<entry �>
@@ -327,18 +358,16 @@
<role>clerk</role>
�
+--------------------------------------
+4.2 Jetspeed 1.4 Declarative Security
+--------------------------------------
This proposal deprecates the old format, and proposes a new format based on the
security descriptor format
proposed a while back by Marcus Schwarz of SAP in Proposal 0004.txt. However some
differences:
-1. There will be no <allow> or <deny> tags. All entries explicitly mean allow.
-2. The 'access' tag renamed to 'action'.
-3. The everyone attribute is dropped
-4. The permission tag dropped
-
--------------------------------
-4.1 Authorization Constraints
--------------------------------
+1. There will be no <deny> tags. All entries are allow only.
+2. The 'everyone' attribute is dropped
+3. The permission tag dropped
An authorization constraint is defined as a security element in either a PSML
element or in a Registry.
Constraints are applied to Portlet Resources. The types of resources that may have
security constraints are:
@@ -346,74 +375,149 @@
1. Portlet entries in the Registry
2. Portlet entries in PSML
3. Portlet sets in PSML
+4. PSML files using the Profile locator format
+5. Any arbitrary resource string that the Security service knows about
-Since the top level portlet set in a PSML 'file' is required, access to a PSML file
can be controlled
-by entering a security check on the top level portlet set in the PSML file.
-
-Authorization constraints are role-based. If the current subject doesn't have the
allowed role,
-the user must be denied access. If the authorization constraint defines no roles,
no user is allowed access
-to the resource defined by the security constraint.
--------------------------------------
-4.2 The Security Constraint Registry
+4.2.1 Security Constraints References
--------------------------------------
-Security constraints can be deployed in a XREG files as common constraints.
-They are standalone, high level registry elements like <portlet-entry>.
-They list the valid roles for the constraint, and the action for which we are
allowing (granting) access
-on the resource.
+Security Constraints are specifically supported by Jetspeed in two places:
- <security-entry id='23923'>
- <role>manager</role>
- <role>clerk</role>
- <user>john</user>
- <action>view</action>
- <action>edit</action>
- <!-- Only managers and clerks can view or edit. No one can customize,... -->
- </security-entry>
+1. The Portlet Registry
+2. PSML
-The security-entry is implementation specific for the default Jetspeed security.
-These entries may be stored by other implementations in policy repository for
example.
+In both cases, the security tag is defined as:
+
+ <security-ref parent='23923'/>
-These master constraints can be referenced by security constraints in PSML or other
registry entries. For example:
+ - where parent is a unique identifier, specific to the Security service provider,
+ identifying a security constraint.
+ - the parent attribute is required
+Example of a Portlet Registry entry:
+---------------------------------------
<portlet-entry>
...
<security-ref parent='23923'/>
</portlet-entry>
+---------------------------------------
+Example of a PSML entry:
+---------------------------------------
-When implementing your own Jetspeed Security, entry ids can be used with external,
centralized policy managers.
-The id can be used to uniquely reference a security constraint in an external
security policy.
+<entry>
+...
+ <security-ref parent='23923'/>
+</entry>
+
+---------------------------------------
+
+See the next section on how the referenced constraints are defined in the default
implementation.
+
+--------------------------------------------------------------
+4.4 The Security Constraint Registry
+--------------------------------------------------------------
+
+The default Jetspeed security service stores its security constraints in a Jetspeed
registry.
+New security constraints are deployed in to Jetspeed as XREG files.
+They are standalone, high level registry elements like <portlet-entry>.
+Constraints list the valid roles and users for the constraint, and the action for
which
+we are allowing (granting) access on the resource.
-----------------------------------------
+<security-entry>
+----------------------------------------
-<security-entry> - Attributes
+Attributes
1. id (required)
-<security-entry> - Elements
+Elements
+
+1. <access>
+
+If no <access> element is specified,
+then everyone is denied access.
+-----------------------------------------
-1. <role>name</role>
-2. <user>user</user>
-3. <action>name</action>
-----------------------------------------
+<access>
+-----------------------------------------
+
+Attributes
-<security-ref> - Attributes
+1. action
+
+
+Elements
+
+1. allow-if
+
+If no action attribute is specified, then the rule applies to all actions.
+If no allow-if element is specified, then access is denied to everyone.
+-----------------------------------------
-1. parent (required)
-<security-ref> - Elements
+-----------------------------------------
+<allow-if>
+-----------------------------------------
+
+Attributes
+
+1. role
+2. user
+3. group
+
+Elements
+
+(none)
+
+If no attributes are specified, the rule applies to all security types(role, user,
group)
+
+-----------------------------------------
+
+
+-----------------------------------------
+Example:
+-----------------------------------------
+
+<security-entry id='pigInAPoke7'>
+ <access action="view">
+ <allow-if role="clerk">
+ <allow-if role="manager">
+ <allow-if user="superman">
+ </access>
+ <access action="customize">
+ <allow-if role="manager" user="superman">
+ </access>
+</security-entry>
+
+-------------------------------------------------------------
+
+The security-entry is implementation specific for the default Jetspeed security.
+Other security service providers will determine where its constraints are stored.
+Other security service providers may optionally (for example):
+
+1. Use the Security Registry files for importing into their own store
+2. Use the default Security Registry files as the constraints persistence store
+3. Use its own policy or other repository
+4. Dynamically load and check constraints from the Jetspeed Security Registry
+
+These master constraints can be referenced by security constraints in PSML or other
registry entries.
+
+When implementing your own Jetspeed Security, entry ids can be used with external,
centralized policy managers.
+The id can be used to uniquely reference a security constraint in an external
security policy.
-None
--------------------------------------
-4.3 Default Behavior
+4.5 Default Behavior of Descriptors
--------------------------------------
It may not be clear what happens when no security descriptor is supplied.
@@ -428,7 +532,7 @@
If you specify a security descriptor without any roles(principals), everyone is
denied.
--------------------------------------
-4.4 Uniqueness of entries
+4.6 Uniqueness of entries
--------------------------------------
In order for all entries to be uniquely identifiable in the portal by the Security
Manager, security ids must be unique
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
