correcting repository ID so that it uses the correct authentication, adding...

See merge request !34

Changes to migrate deployment to gitlab,adding gitlab-ci file

See merge request !33

Migrate_Deployment: Migrating deployment to gitlab, also removing dependencies on external com.gitlab.nblair repo in favor of local gitlab copy of adi-development library

Switch to open releases proxy for distribution

See merge request adi-ia/uw-spring-security!32

Switch to snapshot version to release with mvn plugin

See merge request adi-ia/uw-spring-security!31

Update Spring to Latest Version

See merge request adi-ia/uw-spring-security!30

Test Cleanup

See merge request adi-ia/uw-spring-security!29

Adding display name attribute, updated UDS libraries

See merge request !27

Setting UwframeSession to use fullName as display name if displayName is null. Previously always used fullName, but recent commit set it to always use displayName. This commit splits the difference.

Upgraded UDS services libraries to newer uds-person-client-java 2.0, and the 1.2 data model that includes access to preferred name. Also added displayName attribute to UWUserDetails that should be picked up from Shibboleth displayName header

deprecate: LocalUserDetailsAttributesMapper

I'm preparing a 1.7.0 release, thought I'd stick this in there as well.

See merge request !26

Use LocalUserDetailsLoader instead.

refactor: change injection strategy for UdsPersonUserDetailsServiceImpl

`UdsPersonUserDetailsServiceImpl` is not initialized automatically by either of the primary 'local-users' or 'preauth' Profiles. It's typically constructed by downstream projects manually (not by component scanning).
    
 Registering more than 1 `UserDetailsService` - say one for the uw-spring-security stack, and a different one for `UdsPersonUserDetailsServiceImpl` - will result in ApplicationContext initialization errors as the Configuration classes provided in uw-spring-security-config expect 1 and only 1 UserDetailsService.
    
The recommended use now for `UdsPersonUserDetailsServiceImpl` is to provide the needed `UserDetailsService` by hand, not by automatic autowiring. If the 1 UserDetailsService provided by uw-spring-security is appropriate, it's easy to retrieve from the ApplicationContext; if an alternate one is required it can be constructed without registering it as a @Bean.

See merge request !25

Change to UdsPersonUserDetailsServiceImpl construction necessitates.

UdsPersonUserDetailsServiceImpl is not initialized automatically by either of the primary 'local-users' or 'preauth' Profiles. It's typically constructed by downstream projects manually (not by component scanning).

Registering more than 1 UserDetailsService - say one for the uw-spring-security stack, and a different one for UdsPersonUserDetailsServiceImpl - will result in ApplicationContext initializationerrors as the Configuration classes provided in uw-spring-security-config expect 1 and only 1 UserDetailsService.

The recommended use now for UdsPersonUserDetailsServiceImpl is to provide the needed UserDetailsService by hand, not by automatic autowiring. If the 1 UserDetailsService provided by uw-spring-security is appropriate, it's easy to retrieve from the ApplicationContext; if an alternate one is required it can be constructed without registering it as a @Bean.

Consume isMemberOf attribute as single value with semi-colon delimited list of manifest groups

In the List Library application, which is attempting to consume Manifest groups as UW Spring Security authorities, we discovered that multiple Manifest groups are not provided by the login server as multiple isMemberOf headers but as one string with the Manifest groups delimited by semi-colons.

This PR revises the default Preauth mapper to split the isMemberOf string apart into a Java collection, which is the correct format for the authorities argument to the UWUserDetailsImpl constructor.

Notify: @paul.erickson @ahoffmann @gutkowski @bkeen

See merge request !24