Changes between Version 15 and Version 16 of proposals/ImprovedSecurityArchitecture
- Timestamp:
- 07/17/11 13:15:56 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
proposals/ImprovedSecurityArchitecture
v15 v16 29 29 30 30 == Motivations == 31 This document describes the architecture we propose to enable and enhance the use of various security providers with GeoNetwork opensource. We will give an overview of the current way of dealing with security in GeoNetwork 2.x andGeoNetwork 3.x, after which we will present this proposal in more detail.32 33 This proposal entails the use of [http://static.springsource.org/spring-security/site/ Spring Security], a well-known framework that supports the use of one or several security providers. It also entails the introduction of a dedicated GN security component ( GAAP), which is already in use in GeoNetwork 3.x, intoGeoNetwork 2.x.34 35 === current situation in GeoNetwork 2.x ===36 37 This section describes the implementation of authentication and authorization in the current releases of GeoNetwork 2.x (as also in trunk).31 This document describes the architecture we propose to enable and enhance the use of various security providers with !GeoNetwork opensource. We will give an overview of the current way of dealing with security in !GeoNetwork 2.x and !GeoNetwork 3.x, after which we will present this proposal in more detail. 32 33 This proposal entails the use of [http://static.springsource.org/spring-security/site/ Spring Security], a well-known framework that supports the use of one or several security providers. It also entails the introduction of a dedicated GN security component (!GeoNetwork Authentication & Authorization Provider, GAAP), which is already in use in !GeoNetwork 3.x, into !GeoNetwork 2.x. 34 35 === current situation in !GeoNetwork 2.x === 36 37 This section describes the implementation of authentication and authorization in the current releases of !GeoNetwork 2.x (as also in trunk). 38 38 39 39 ==== Users and Groups ==== 40 40 41 GeoNetwork maintains DBMS tables for Users and Groups. A User is an entity that can log in, log out, has a Profile (this is best understood as a Role), and is part of one or more Groups. Access to metadata is restricted by Profile and Group. The Group privileges to access a metadata are stored in a DBMS table and also in the Lucene index. In the code these access privileges are overridden by checking on Profile (esp. Users with Profile "Administrator" are permitted access to all metadata). The metadata access is further specified in access types (View, Edit, and a few other ones).41 !GeoNetwork maintains DBMS tables for Users and Groups. A User is an entity that can log in, log out, has a Profile (this is best understood as a Role), and is part of one or more Groups. Access to metadata is restricted by Profile and Group. The Group privileges to access a metadata are stored in a DBMS table and also in the Lucene index. In the code these access privileges are overridden by checking on Profile (esp. Users with Profile "Administrator" are permitted access to all metadata). The metadata access is further specified in access types (View, Edit, and a few other ones). 42 42 43 43 ==== LDAP ==== 44 44 45 It is possible to configure an external LDAP security provider. In this case, after a successful login, the User information obtained from LDAP is temporarily inserted into the GeoNetwork Users DBMS table. When the session ends (upon logout or expiration) they remain in the database. It is not possible to configure more than one LDAP provider.46 47 === current situation in GeoNetwork 3.x ===48 49 This section describes the implementation of authentication and authorization in the current branch of GeoNetwork 3.x.50 51 In GeoNetwork 3.x the picture is slightly changed because of the introduction of a new, separate Web application, GeoNetwork CSW/ebRIM. This application restricts access to its ebRIM metadata based on the privileges for the ISO19139 metadata (in "Legacy" GeoNetwork) that the ebRIM metadata was created for. In order to separate concerns an extra new Web application was introduced, GAAP (GeoNetwork Authentication & Authorization Application).52 53 The GeoNetwork Users and Groups DBMS tables, as well as the metadata privileges table in GeoNetwork 3.x are moved to GAAP. GeoNetwork CSW/ebRIM consults GAAP to control access to its ebRIM metadata. LegacyGeoNetwork consults GAAP to control access to its metadata.45 It is possible to configure an external LDAP security provider. In this case, after a successful login, the User information obtained from LDAP is temporarily inserted into the !GeoNetwork Users DBMS table. When the session ends (upon logout or expiration) they remain in the database. It is not possible to configure more than one LDAP provider. 46 47 === current situation in !GeoNetwork 3.x === 48 49 This section describes the implementation of authentication and authorization in the current branch of !GeoNetwork 3.x. 50 51 In !GeoNetwork 3.x the picture is slightly changed because of the introduction of a new, separate Web application, !GeoNetwork CSW/ebRIM. This application restricts access to its ebRIM metadata based on the privileges for the ISO19139 metadata (in "Legacy" !GeoNetwork) that the ebRIM metadata was created for. In order to separate concerns an extra new Web application was introduced, GAAP (!GeoNetwork Authentication & Authorization Provider). 52 53 The !GeoNetwork Users and Groups DBMS tables, as well as the metadata privileges table in !GeoNetwork 3.x are moved to GAAP. !GeoNetwork CSW/ebRIM consults GAAP to control access to its ebRIM metadata. Legacy !GeoNetwork consults GAAP to control access to its metadata. 54 54 55 55 === outline of proposed changes === … … 60 60 * add support for [http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language SAML]-based authentication (Single-Sign On) 61 61 * allow for the use of other types of external security providers 62 * improve on the implementation when using GeoNetwork Authentication and/or one or more external security providers63 * improve performance as compared to the current GeoNetwork 3.x code64 * The proposal involves the introduction of GAAP in GeoNetwork 2.x and modifications to the working of GAAP and LegacyGeoNetwork.62 * improve on the implementation when using !GeoNetwork Authentication and/or one or more external security providers 63 * improve performance as compared to the current !GeoNetwork 3.x code 64 * The proposal involves the introduction of GAAP in !GeoNetwork 2.x and modifications to the working of GAAP and Legacy !GeoNetwork. 65 65 66 66 … … 71 71 ==== security token map ==== 72 72 73 GeoNetwork maintains an in-memory map of security tokens, !SecurityTokenMap. This map associates a session id with a security token. The token contains all informationGeoNetwork uses to allow access to its resources: the User Profile and list of Groups the User is part of. When determining access rights, the metadata privileges as stored in the DBMS and Lucene (depending on type of access -- Lucene is used for free text searches) are compared to the Groups found in the security token in the current session.73 !GeoNetwork maintains an in-memory map of security tokens, !SecurityTokenMap. This map associates a session id with a security token. The token contains all information !GeoNetwork uses to allow access to its resources: the User Profile and list of Groups the User is part of. When determining access rights, the metadata privileges as stored in the DBMS and Lucene (depending on type of access -- Lucene is used for free text searches) are compared to the Groups found in the security token in the current session. 74 74 75 75 ==== security servlet filter ==== 76 76 77 A servlet filter intercepts all requests to GeoNetwork and verifies whether the current session id is present in !SecurityTokenMap. If it is, nothing special happens and the request continues to its destination service inGeoNetwork. If the session id is not in !SecurityTokenMap, the filter requests GAAP for an anonymous security token. The session id is mapped to this anonymous token and stored in !SecurityTokenMap.77 A servlet filter intercepts all requests to !GeoNetwork and verifies whether the current session id is present in !SecurityTokenMap. If it is, nothing special happens and the request continues to its destination service in !GeoNetwork. If the session id is not in !SecurityTokenMap, the filter requests GAAP for an anonymous security token. The session id is mapped to this anonymous token and stored in !SecurityTokenMap. 78 78 79 79 ==== logging in ==== 80 80 81 When a User is logging in, the login form is requested from GAAP. GAAP uses Spring Security to access one or more security providers. If the credentials provided in the login form can be matched against one of them, a security token is created that contains all required information, the User's name (and possibly other info like contact details), Profile, and list of Groups. This security token is returned to GeoNetwork that adds or updates the entry for the current session in !SecurityTokenMap. When the User logs out or the session expires the corresponding entry is removed from !SecurityTokenMap.81 When a User is logging in, the login form is requested from GAAP. GAAP uses Spring Security to access one or more security providers. If the credentials provided in the login form can be matched against one of them, a security token is created that contains all required information, the User's name (and possibly other info like contact details), Profile, and list of Groups. This security token is returned to !GeoNetwork that adds or updates the entry for the current session in !SecurityTokenMap. When the User logs out or the session expires the corresponding entry is removed from !SecurityTokenMap. 82 82 83 83 ==== logged in ==== … … 87 87 ==== administration ==== 88 88 89 Users with Profile "Administrator" are authorized to manage Groups, Users, and configure external (e.g. LDAP) security providers. The actual DBMS and web pages enabling this currently reside in GeoNetwork, but in our proposed architecture this belongs in GAAP. So we'll move the administration of users and groups, and also the configuration of security providers, to GAAP.89 Users with Profile "Administrator" are authorized to manage Groups, Users, and configure external (e.g. LDAP) security providers. The actual DBMS and web pages enabling this currently reside in !GeoNetwork, but in our proposed architecture this belongs in GAAP. So we'll move the administration of users and groups, and also the configuration of security providers, to GAAP. 90 90 91 91 The security provider configuration data is stored in a !SecurityProvider DBMS table and dynamically applied to the Spring Security configuration. Security providers may be marked as ACTIVE or INACTIVE by the Administrator. When performing an authorization, GAAP's Spring Security will only consult the security providers marked as ACTIVE. … … 97 97 [[Image(component-model.png)]] 98 98 99 === GeoNetwork application ===100 101 This section discusses the changes to the GeoNetwork application.102 103 GeoNetwork uses session to maintain state about the privileges of the current user. This remains exactly the same in this proposal.99 === !GeoNetwork application === 100 101 This section discusses the changes to the !GeoNetwork application. 102 103 !GeoNetwork uses session to maintain state about the privileges of the current user. This remains exactly the same in this proposal. 104 104 105 105 ==== authentication ==== 106 106 107 The main difference lies in how the authentication is performed. In this proposal GeoNetwork delegates authentication to GAAP; the result of this authentication is a !SecurityToken returned by GAAP and associated to the current session.108 109 A UML Activity diagram giving a high-level view of GeoNetwork delegating to GAAP is this:107 The main difference lies in how the authentication is performed. In this proposal !GeoNetwork delegates authentication to GAAP; the result of this authentication is a !SecurityToken returned by GAAP and associated to the current session. 108 109 A UML Activity diagram giving a high-level view of !GeoNetwork delegating to GAAP is this: 110 110 111 111 [[Image(GeoNetworkSecurityFilterActivity.png)]] 112 112 113 Because the Users and Groups DBMS tables are moved to GAAP, their information is part of the !SecurityToken; where currently GeoNetwork has numerous places where it consults the DBMS to look up the current user's groups, these lookups are modified to use the !SecurityToken instead. !SecurityTokens are kept in an application-scope map, with session-id as the key to look them up. If the user does not log in, the !SecurityToken is an anonymous !SecurityToken.114 115 The delegation is handled by a Servlet Filter, GeoNetwork Security Filter. This filter intercepts all requests to GeoNetwork, checks if the current session id is known in the !SecurityToken Map and if not, it forwards the request to GAAP. GAAP returns a !SecurityToken that is added to the Map, so subsequent requests from the same client (as long as the session is valid) do not need to consult GAAP again. After this, GeoNetwork Security Filter lets the request continue normally to its destination (one of theGeoNetwork services).116 117 A more detailed UML Sequence diagram showing GeoNetwork delegating to GAAP is this:113 Because the Users and Groups DBMS tables are moved to GAAP, their information is part of the !SecurityToken; where currently !GeoNetwork has numerous places where it consults the DBMS to look up the current user's groups, these lookups are modified to use the !SecurityToken instead. !SecurityTokens are kept in an application-scope map, with session-id as the key to look them up. If the user does not log in, the !SecurityToken is an anonymous !SecurityToken. 114 115 The delegation is handled by a Servlet Filter, !GeoNetwork Security Filter. This filter intercepts all requests to !GeoNetwork, checks if the current session id is known in the !SecurityToken Map and if not, it forwards the request to GAAP. GAAP returns a !SecurityToken that is added to the Map, so subsequent requests from the same client (as long as the session is valid) do not need to consult GAAP again. After this, !GeoNetwork Security Filter lets the request continue normally to its destination (one of the !GeoNetwork services). 116 117 A more detailed UML Sequence diagram showing !GeoNetwork delegating to GAAP is this: 118 118 119 119 [[Image(GeoNetworkSecurityFilterSequence.png)]] … … 121 121 A short description of the steps in the above sequence diagram: 122 122 123 1. Clients sends a request to GeoNetwork, which is intercepted by !GeoNetworkSecurityFilter123 1. Clients sends a request to !GeoNetwork, which is intercepted by !GeoNetworkSecurityFilter 124 124 2. !GeoNetworkSecurityFilter retrieves !SecurityTokenMap from application scope 125 125 3. !GeoNetworkSecurityFilter retrieves the current session id … … 127 127 5. If not, !GeoNetworkSecurityFilter forwards the request to GAAP's !AuthenticationService; GAAP responds with a !SecurityToken 128 128 6. !GeoNetworkSecurityFilter adds the !SecurityToken to !SecurityTokenMap 129 7. !GeoNetworkSecurityFilter calls the method "authenticate()" in Jeeves !UserSession. For non-anonymous users this means, login to GeoNetwork129 7. !GeoNetworkSecurityFilter calls the method "authenticate()" in Jeeves !UserSession. For non-anonymous users this means, login to !GeoNetwork 130 130 8. !GeoNetworkSecurityFilter sets !UserSession in session scope 131 9. The request continues normally to its GeoNetwork service destination131 9. The request continues normally to its !GeoNetwork service destination 132 132 10. The service response is returned to the client 133 133 134 134 ==== login ==== 135 135 136 In the login service, GeoNetwork delegates authentication to GAAP. The UML Sequence diagram showingGeoNetwork login is this:136 In the login service, !GeoNetwork delegates authentication to GAAP. The UML Sequence diagram showing !GeoNetwork login is this: 137 137 138 138 [[Image(GeoNetworkLoginSequence.png)]] … … 140 140 ==== logout ==== 141 141 142 In the logout service GeoNetwork the !UserSession and !SecurityToken are removed. Next request toGeoNetwork will request to GAAP a new !SecurityToken, that can be either an anonymous !SecurityToken (if no authentication is attempted) or a !SecurityToken containing details about the authenticated user.143 144 The UML Sequence diagram showing GeoNetwork logout is this:142 In the logout service !GeoNetwork the !UserSession and !SecurityToken are removed. Next request to !GeoNetwork will request to GAAP a new !SecurityToken, that can be either an anonymous !SecurityToken (if no authentication is attempted) or a !SecurityToken containing details about the authenticated user. 143 144 The UML Sequence diagram showing !GeoNetwork logout is this: 145 145 146 146 [[Image(GeoNetworkLogoutSequence.png)]] … … 148 148 A short description of the steps in the above sequence diagram: 149 149 150 1. Client sends a request to GeoNetwork logout service150 1. Client sends a request to !GeoNetwork logout service 151 151 2. The session is invalidating, removing the !UserSession information 152 152 3. !SecurityToken is removed from !GeoNetworkSecurityTokenMap 153 4. The client is forwarded to GeoNetwork main page153 4. The client is forwarded to !GeoNetwork main page 154 154 155 155 156 156 ==== other changes ==== 157 157 158 Some other changes to the GeoNetwork application foreseen by this proposal are:158 Some other changes to the !GeoNetwork application foreseen by this proposal are: 159 159 160 160 * move Login form, and Users and Groups DBMS tables to GAAP: this is about authentication, so should be located in the dedicated Authentication application (GAAP) 161 161 * move administration GUI pages related to the above DBMS tables to GAAP 162 * change lookups in GeoNetwork code to the above DBMS tables, to lookup the info in !SecurityTokenMap instead the login form and the non-GUI login ("xml login") delegate the act of logging in to GAAP162 * change lookups in !GeoNetwork code to the above DBMS tables, to lookup the info in !SecurityTokenMap instead the login form and the non-GUI login ("xml login") delegate the act of logging in to GAAP 163 163 164 164 === GAAP application === … … 181 181 One or more security providers need to be configured and active so that GAAP has at least one source to authenticate against. They can be of many different types that are supported out-of-the-box by Spring Security. Some examples: JDBC, LDAP, SAML-based, Open-ID based, in-memory (specified only in Spring Security itself). 182 182 183 The classic GeoNetwork Users DBMS table, having moved from theGeoNetwork application to the GAAP application, is treated exactly as any other security provider, except that it is the default if you don't configure anything else. To make sure that the super-super-user "admin" is always available to GAAP, it is configured in an in-memory security provider to Spring Security.183 The classic !GeoNetwork Users DBMS table, having moved from the !GeoNetwork application to the GAAP application, is treated exactly as any other security provider, except that it is the default if you don't configure anything else. To make sure that the super-super-user "admin" is always available to GAAP, it is configured in an in-memory security provider to Spring Security. 184 184 185 185 Users with role Administrator can use the GAAP GUI administrative pages to configure one or more security providers. Security providers can be ACTIVE or INACTIVE; if INACTIVE their configuration is still there but they are not used in the Spring Security authenticating !FilterChain. … … 187 187 ==== userproperties ==== 188 188 189 You may remember from the description of current GeoNetwork 2.x that in case LDAP authentication is used, the LDAP users are inserted into the GeoNetwork Users table, where they remain even when their session ends. The reason for this is that an Administrator might decide to change these users' groups or role, and it would be impractical to do this everytime again when an LDAP user logs in. One drawback of the current implementation is of course that previously existing data in the Users table simply gets overwritten when this happens; switching between JDBC and LDAP authentication in currentGeoNetwork is definitely not recommended without extra safeguards like backing up the database before making such a switch.189 You may remember from the description of current !GeoNetwork 2.x that in case LDAP authentication is used, the LDAP users are inserted into the !GeoNetwork Users table, where they remain even when their session ends. The reason for this is that an Administrator might decide to change these users' groups or role, and it would be impractical to do this everytime again when an LDAP user logs in. One drawback of the current implementation is of course that previously existing data in the Users table simply gets overwritten when this happens; switching between JDBC and LDAP authentication in current !GeoNetwork is definitely not recommended without extra safeguards like backing up the database before making such a switch. 190 190 191 191 All this is of course no longer a problem in this proposed solution; not only can you switch between various security providers, you can also use them at the same time. Still, some data related to users should still be persisted; for example when an Administrator changes an LDAP user's groups or role. For this reason, everytime a successful non-anonymous authentication has been made, the information contained in !SecurityToken is also persisted in the DBMS table !UserProperties. … … 193 193 === GAAP Administrative GUI === 194 194 195 The pages in the GeoNetwork admin section that deal with Users and Groups are moved to the GAAP web application. In theGeoNetwork "system configuration" page, which operates on the DBMS table Settings, currently some authentication sources can be configured, to wit an LDAP provider or a Shibboleth source. These are removed from that page. In GAAP a page dedicated to security provider configuration is introduced. Administrator users can configure one ore more security providers and flip their ACTIVE/INACTIVE state. This configuration is persisted in the GAAP DBMS table !SecurityProviders, and is also (when changed) applied on-the-fly to the Spring Security configuration so changes take immediate effect.195 The pages in the !GeoNetwork admin section that deal with Users and Groups are moved to the GAAP web application. In the !GeoNetwork "system configuration" page, which operates on the DBMS table Settings, currently some authentication sources can be configured, to wit an LDAP provider or a Shibboleth source. These are removed from that page. In GAAP a page dedicated to security provider configuration is introduced. Administrator users can configure one ore more security providers and flip their ACTIVE/INACTIVE state. This configuration is persisted in the GAAP DBMS table !SecurityProviders, and is also (when changed) applied on-the-fly to the Spring Security configuration so changes take immediate effect. 196 196 197 197 The GAAP Administrative GUI also allows Administrator users to configure some of GAAP's behaviour. The following options are available: … … 199 199 * User Properties strategy. Administrator users can edit user's role and groups in GAAP. It is possible that the security provider that has authenticated a user has provided some or all of that information (more likely 'role' info) originally. If the option GAAPONLY is selected, GAAP will henceforth only use the (Administrator-changed) user information and ignore any info from the security provider the next time this user logs in. This is also the default. If the option EXTERNAL is selected, GAAP will each time look at the info from the security provider and overwrite any changes made to it in GAAP by an Administrator. 200 200 201 Although the GAAP Administrative pages reside in the GAAP web application, they will be transparently made accessible through the same links in the GeoNetwork Admin page. The GAAP GUI is also accessible through its own,GeoNetwork-independent base URL.201 Although the GAAP Administrative pages reside in the GAAP web application, they will be transparently made accessible through the same links in the !GeoNetwork Admin page. The GAAP GUI is also accessible through its own, !GeoNetwork-independent base URL. 202 202 203 203 The GAAP GUI runs on Spring MVC, using JSP with Sitemesh. … … 217 217 * User is allowed to select IDP from the list of configured ones; entry point then redirects user to the selection page. 218 218 219 SP-initiated flow is to say, the user's Single Sign-On identity is created by the user starting at the GeoNetwork (the Service Provider). GAAP's login form shows a list of all trusted Identity Providers; the user can choose one, and upon submit is redirected to that Identity Provider's login form. After authentication at the Identity Provider the user comes back toGeoNetwork.220 221 IDP-initiated flow is when the user has already authenticated with a trusted Identity Provider when doing a request to GeoNetwork; in this case the request carries a SAML Authentication token that is validated by GAAP and if valid, allows the user Single-!SignOn access toGeoNetwork.219 SP-initiated flow is to say, the user's Single Sign-On identity is created by the user starting at the !GeoNetwork (the Service Provider). GAAP's login form shows a list of all trusted Identity Providers; the user can choose one, and upon submit is redirected to that Identity Provider's login form. After authentication at the Identity Provider the user comes back to !GeoNetwork. 220 221 IDP-initiated flow is when the user has already authenticated with a trusted Identity Provider when doing a request to !GeoNetwork; in this case the request carries a SAML Authentication token that is validated by GAAP and if valid, allows the user Single-!SignOn access to !GeoNetwork. 222 222 223 223 The AuthNRequest SAML message is sent to the IDP using either HTTP-POST or HTTP-Redirect binding and the request is stored in the cache for subsequent matching with the response. … … 254 254 * [http://wiki.osgeo.org/wiki/User:Heikki Heikki Doeleman] 255 255 * [http://wiki.osgeo.org/wiki/User:Josegar Jose Garcia] 256