Changes between Version 12 and Version 13 of proposals/ImprovedSecurityArchitecture

Timestamp:

Dec 15, 2010, 9:49:44 AM (14 years ago)

Author:

heikki

Comment:

--

proposals/ImprovedSecurityArchitecture

@@ -175 +175 @@
 [[Image(SpringSecurityAuthenticationServiceActivity.png)]]
 
+A succesful request to !AuthenticationService causes it to return a !SecurityToken to the client application; this can be either an anonymous !SecurityToken (if no authentication was attempted) or a !SecurityToken containing details about the authenticated user. A failed login attempt causes the Spring Security !FilterChain to throw an exception, which itself is processed in a later filter in this chain, so that a response indicating the failed login condition is returned along with an anoymous !SecurityToken.
+
+==== security providers ====
+
+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).
+
+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.
+
+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.
+
+==== userproperties ====
+
+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.
+
+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.
+
+=== GAAP Administrative GUI ===
+
+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.
+
+The GAAP Administrative GUI also allows Administrator users to configure some of GAAP's behaviour. The following options are available:
+
+ * 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.
+
+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.
+
+The GAAP GUI runs on Spring MVC, using JSP with Sitemesh.
+
+=== saml 2.0 security provider ===
+
+We will use the standard Spring Security Extension for SAML. This library is able to authenticate users against any SAML 2.0 compatible Identity Provider. Some of the features we support are:
+
+    * Both Service Provider (SP) and Identity Provider (IDP) initiated !WebSSO profile of the SAML v2 protocol stack
+    * HTTP-POST and HTTP-Redirect bindings
+    * Automatic generation of Service Provider metadata
+    * Configuration of multiple !IDPs
+
+GAAP support for SAML can function in one of the two modes of IDP discovery:
+
+    * A default IDP has been configured which is then always used
+    * User is allowed to select IDP from the list of configured ones; entry point then redirects user to the selection page.
+
+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.
+
+!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.
+
+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.
+
+All configured IDPs are considered to be members of a single circle of trust.
+
+The SAML Single log-out profile is currently not supported, invocation of logout at will only destroy the local session.
+
+A UML Activity diagram giving a view of how GAAP manages a SP-initiated !WebSSO is:
+
+[[Image(SAMLAuthenticationActivity.png)]]
+
 
 === Backwards Compatibility Issues ===