feature: a callback interface allowing customization of UserDetailsService#loadUserByUsername

This pull request adds a callback interface that allows downstream projects to participate in one of the core Spring Security components of the `local-users` profile: the UserDetailsService.

During an authentication attempt, `UserDetailsService#loadUserByUsername` is used by Spring Security to first check if a User object exists for the username in the credentials. If no User object is found, no further credential check takes place; if a User object is found, other Spring Security components go about comparing the provided credentials in the authentication attempt to that object.

We have a use case in DoIT Number that is driving the need for this. DoIT Number has a custom `UWUserDetails` class that has some additional fields stored behind a DAO. If we didn't have this customization, DoIT Number would need to sub-class `LocalUserDetailsManagerImpl`, then somehow exclude that bean from the UWSpringSecurityConfiguration - not trivially possible.

The existing `LocalUserDetailsAttributesMapper` interface has a lifecycle that's not conducive to this type of request. Implementations of that interface are executed during application startup - and it is possible that the DAO may not be fully constructed at the time it's queried. We need a callback that fires at time of authentication attempt - not startup.
 
With this pull request, DoIT Number will simply have to register a Spring Bean as follows to query that DAO and attach the necessary data to their custom `UWUserDetails` class as part of `UserDetailsService#loadUserByUsername`:

```
@Component
class DNumberLocalUWUserDetailsCallback implements LocalUWUserDetailsCallback<DNumberUserDetailsImpl> {

  @Autowired
  private ControlDao controlDao;

  public void success(DNumberUserDetailsImpl userDetails) {
    userDetails.setControls(controlDao.getControls(userDetails.getUsername()));
  }
}
```

This type of feature is only needed for `local-users` and not for `preauth`. The `PreauthenticatedUserDetailsAttributeMapper` interface has a lifecycle already similar to LocalUWUserDetailsCallback (firing on authentication attempt, not startup). 

Notify @alundholm 

See merge request !12

Allows downstream projects to mutate the UWUserDetails instance returned by that core method.

New feature: simulated shibboleth session handler.

Incorrectly had 1.0.3-SNAPSHOT hardcoded, should just match project.version

feature: Add uw-frame compatible REST API for /profile

This pull request adds a REST resource under `/profile` that transforms the current `UWUserDetails` into a format matching [uw-frame's session.json feed](https://github.com/UW-Madison-DoIT/uw-frame/blob/master/uw-frame-components/staticFeeds/session.json).

With this feature in place, uw-frame apps will be able to have the user attributes from the UW Spring Security principal display in the frame header.

Here's the familiar Amy Administrator, as output from `GET /profile/uw-frame`:

```
{
  username: "admin",
  displayName: "Amy Administrator",
  firstName: "Amy",
  lastName: "Administrator",
  serverName: "",
  version: "",
  sessionKey: ""
}
```

To configure this feature in a uw-frame app, one needs to create a file named `src/main/webapp/js/override.js` (if not already present) with the following contents:

```
define(['angular'], function(angular) {
    var config = angular.module('override', []);
    config
        .constant('OVERRIDE', {
            'SERVICE_LOC': {
                'sessionInfo' : 'profile/uw-frame',
            }
        })
    ;
    return config;
});
```

Notify @andrew-petro @levett @ahoffmann @paul.erickson @bjsousa @andrew-summers @alundholm 

To assignee @dwitter2 - the plan is to use this for capital-equipment and iaa-diagnostic-tool, among others, then we no longer have the mismatch in our demos (with frame defaulting to showing one logged in as 'Bucky'). 

See merge request !10

Now matches uw-frame format exactly.

Was accidentally nesting one folder too deep, e.g. /profile/profile.

Due to new features.

Add PviAttributeBindingFilter

AttributeBindingFilter is a filter that is used along with
rest-proxy to add headers to a request based on the attributes added
with the filter.

WIP for suggestions/critiques on the design and implementation.

Please review: @paul.erickson @ahoffmann @bjsousa 

See merge request !9

PviAttributeBindingFilter is a filter that binds the currently
authenticated user's PVI to the request as an attribute with the key
"wiscedupvi".

Switch to Map<String, String> for attributes

Using a Map allows for multiple attributes to be added to the request.

Change to AttributeBindingFilter for user specific attributes

Filter supports UWUserDetails style attributes (such as `wiscedupvi`) for
adding attributes specific to an authenticated user to a request.

Change to PviAttributeBindingFilter

The filter only needs to add a user's PVI as an attribute.

Add type check for principal

Principal is not always guaranteed to be a UWUserDetails instance at the
point it will hit this filter.

UdsPersonUserDetailsImpl#getPvi now returns computed PVI

PVI was returning null in previous version.

See merge request !8

Noise was copied from Spring Security SwitchUserFilter, not relevant to this use case, as it applies to every request, not just a special login attempt.

Change return types for 4 spring UserDetails booleans to true

These 4 fields influence behavior of a lot of Spring Security components. When they were previously set to false, these users could not log in or pass any authorization checks.

See merge request !7

These 4 fields influence behavior of a lot of Spring Security components. When they were previously set to false, these users could not log in or pass any authorization checks.

Add IdentifiersFactory for more configurable UDS UserDetailsService

Defaults to same behavior (treat argument to loadUserByUsername as a NetID username), but allows for easy override with PVI and others.

Use case: consider STAR. star-war supports impersonation via 'On-Behalf-Of' header. Inside the `SwitchUserOnHeaderFilter` is a reference to a `UserDetailsService`. The user attribute value of the 'On-Behalf-Of' header is passed into that `UserDetailsService#loadUserByUsername(String)` method.
Prior to this contribution, `UdsPersonUserDetailsServiceImpl` could ONLY accept a NetID username. 

This contribution defaults to that same behavior. However, if one wants to use a different user attribute, they would simply add a `@Bean` to their Spring ApplicationContext:

```java
@Bean
public IdentifiersFactory pviIdentifiersFactory() {
  return new IdentifiersFactory.PVI();
}
```

With the magic of `@Autowired(required=false)`, the default Netid configuration is replaced, and one can now pass PVIs into the `SwitchUserOnHeaderFilter`.

A few other interested parties: @paul.erickson @ahoffmann @bjsousa 

See merge request !6

Defaults to same behavior (treat argument to loadUserByUsername as a NetID username), but allows for easy override with PVI and others.

Relocate /required and /lazy handlers to sample

Previous presence on ProfileController resulted in those APIs leaking to downstream consumers of uw-spring-security-web.
Also adds an HttpSecurityAmender for configuring auth for /profile.

Bump to version 1.0.0-SNAPSHOT.

Other interested parties: @ahoffmann @paul.erickson @bjsousa 

See merge request !5

Previous presence on ProfileController resulted in those APIs leaking to downstream consumers of uw-spring-security-web.
Also adds an HttpSecurityAmender for configuring auth for /profile.

Bump to version 1.0.0-SNAPSHOT.

Re-organize README, split off contribution guide

This pull request is a starting point for improving the documentation prior to the upcoming brownbag.

Starting with the README and contribution guide, I'll be poring over the existing docs trying to come up with examples. I'm thinking the wiki here in git.doit will be helpful as well.

See merge request !4

Correctly support fallback to local-users in the absence of SAML2 attributes when both local-users and preauth are active

The theme for this pull request:

![highlander](/uploads/f5de15a7b74cf0ba100c8326410f2eb2/highlander.jpg)

This refactor was needed as the prior code did not fully support the 'combined' approach with both local-users and preauth. In the previous iteration, 2 `WebSecurityConfigurerAdapters` and as a result, 2 `HttpSecurity` instances would have been registered, only one having any affect (typically the preauth, but not guarantees). Spring Security does not provide support for multiple `HttpSecurity` instances, there should be only one.
    
With this pull request, there is now only one WebSecurityConfigurerAdapter, whose sole purpose is to collect all HttpSecurityAmenders and execute their callback at the right time.  Te existing WebSecurityConfiguration classes for both profiles have been retrofitted to produce HttpSecurityAmenders that perform the desired behavior. The test cases provided in the sample-war have been updated to provide 2 combined test paths:
    
* 1 that has both profiles active, but demonstrates how fallback to HTTP Basic works, and
* 1 that has both profiles active, and includes the simulation filter to produce a successful preauthentication.

See merge request !3