1. LDS Account and the Java Stack

2. This is a training NOT a presentation. Please ask questions
Disclaimer
This is a training NOT a presentation.
Be prepared to learn and participate in labs
Please ask questions
Prerequisites:
Basic Java knowledge
Basic Spring knowledge
A few disclaimers to get things started.

3. Spring Security Overview
Outline
LDS Account Overview
History
Authentication
User Details
Spring Security Overview
LDS Account integration
In memory integration
LDS Account Search
Spring Security and Authorization
This training is meant to be a comprehensive introduction to the Java Stack's integration with LDS Account. It will cover authentication integration with Spring Security as well as a consistent interface for accessing user information for authenticated users.

4. Historically each application handled authentication as a one off
History
Historically each application handled authentication as a one off
Troublesome for users (many credentials to remember)
User information duplicated over and over throughout the enterprise
Difficult to get user information at all
Screaming for consolidation and a single, central solution
Let’s start out with a little bit of history to help us better understand LDS Account:
In the olden days (like a few years ago) just about every application had its own authentication mechanism and source, and this was duplicated throughout the organization
Not only was this troublesome for users, as they had to remember different credentials for each application, but, there was massive duplication of user information across the enterprise. That said, it was still very, very difficult to find out member leader information like callings, unit, address as well as employment information, membership information, ect.
If there ever was a place where we could have huge savings by doing something once centrally, this was it. And, in hindsight, it has been a huge success.

5. LDS Account
"LDS Account is a single user name and password for any person who interacts with online LDS Church resources. LDS Account is the primary account authentication credentials for most Church sites and applications. It reduces development costs that would be incurred as the user interfaces change, or as upgrades to security and the registration process are required. Unlike previous authentication systems, LDS Account is a branded single sign-on solution that is centrally managed at ldsaccount.lds.org."
From the LDS Account team’s documentation …

6. LDS Account (cont.)
"LDS Account has become the key to accessing all the resources the Church has to offer, such as family history tools, ward and stake websites, employment resources, and more. ... The idea is to have only one username and password that you can use with all password-protected websites the Church has."

7. LDS Account is implemented with LDAP
What is LDS Account?
LDS Account is meant to be the single source for user authentication and basic user information
LDS Account is implemented with LDAP
LDS Account is an application for maintaining user attributes
LDS Account is a few things that are often used interchangeably.
In concept, LDS Account is meant to be the single source for user authentication and basic user information
In application, LDS Account is a group of synchronized LDAP servers that store information about each user in LDAP attributes
Tools surrounding the management of these users and their attributes are also sometimes referred to as LDS Account. For instance there is an LDS Account web application (called LDS Account) where a user can manage their account.
For our discussion today and in general, when we say LDS Account, we mean the concept of a single source for user authentication, and its implementation via LDAP. We do not plan to focus on the application for managing the LDS Account attributes in this training.
LDS Account is hands down one of the most successful and beneficial endeavors ever taken on in ICS. Even Family History uses it There is so much time, money, and hair pulling saved by LDS Account that it is almost incalculable. Since its introduction it has become wildly popular and the organization has never looked back. As such, I would like to tell you that the Stack team implemented LDS Account, but we didn’t. We are not the LDS Account team, but we provide integrations with LDS Account to make using it even easier. These integrations will be the focus of this training.

8. Lightweight Directory Access Protocol
LDS Account Uses LDAP
Lightweight Directory Access Protocol
Distributed directory of information
Much like a database
Not queried with SQL
For further information about the Directory structure, please see the corresponding section at:
LDS Account = LDAP
WAM = Single Sign-on
So, for the purposes of our discussion, LdsAccount is an LDAP based data store. LDAP stands for Lightweight Directory Access Protocol, which is a protocol for accessing distributed directory information. Often when people refer to LDAP they are not referring to the protocol but the distributed directory itself in which the information is stored and accessed using the protocol. So think of LDS Account as a directory of information for users, including authentication credentials. LDAP could be thought of as a database, which is not queried using SQL (i.e. the original no sql database). Each entry in LDAP is an entity (one of which could be a user account) which consists of a set of attributes. Each attribute has a name and value(s).
LDS Account does not provide single sign-on itself, but allows the user to sign into many different applications with the same credentials. The single sign-on solution built on LDS Account is called WAM and will be discussed in a later training.

9. LDS Account also provides user information
User Details
LDS Account also provides user information
User details
User details can be exposed through
LDAP attributes
WAM headers
SAML attributes
While the LDS Account team’s documentation focuses on user authentication (i.e. username and password), which is certainly a significant part of LDS Account, further information about a user (user details) is also stored for each user in LDAP attributes – information such as callings, unit(s), names, birthdate, ect.
There are many different ways to authenticate against LDS Account (LDAP directly, WAM, SAML) . User details are communicated differently depending on the authentication mechanism used. In the case of LDAP you are directly querying attributes out of LDAP. In the case of WAM these details are communicated through HTTP Headers.
Regardless of the mechanism used to communicate the attributes, this information originated in LDAP, which is the master source for authentication and user information.

10. LDS Account User Details Integration
The LDS Account module acts as a Java model for LDS Account information
LdsAccountDetails.java is the abstraction layer for LDS Account user details integration
Factories generate LdsAccountDetails object for each user
Factories handle the different formats in which the raw user details attributes are provide to the application
LDAP attributes, WAM headers, SAML, …
The Stack lds account module acts as a Java model for lds account, holding the user detail information, and exposing it to the application.
We provide different factories for creating LdsAccountDetails objects from the differing sources (LDAP, WAM, and SAML – in the future)
Factories handle the differences and complexity of creating model objects based on the differing authentication attribute systems. For instance, if the information comes from LDAP attributes, or, WAM headers, or, any number of authentication sources, we have a factory, or a factory can be created that transforms the data into a common LdsAccountDetails object. Thus, LdsAccountDetails is the common abstraction layer, insulating the application from these differences and providing a consistent interface for accessing a user’s information regardless of the authentication mechanism being used.

11. https://tech.lds.org/wiki/LDS_Account_Integration_-_Part_1#Lab_1
Lab 1
In this lab we will become a little more acquainted with the LdsAccountDetails object.

12. LDS Account Spring Security Integration
Next we will discuss the LDS Account integration with Spring Security.

13. Authentication vs. Authorization
Authentication - "you are who you say you are"
Identification of an individual user of the application
Credential-based authentication
Authorization - "you have appropriate permissions to perform the operation you are attempting"
Availability of functionality and data to users who are authorized (or allowed) to access it
To start off with, it is important to understand some terminology and in particular authentication vs. authorization.
Authentication means that “you are who you say you are”, and such identification verification can be performed using credential-based authentication – as in a username and a password. If the user can appropriately provide these, then we assume they are who they say they are - i.e. they are authentic, legitimate users of the application.
Once a person is authenticated, the application maintains a reference to some sort of information about this individual, often referred to as a principal.
After someone has authenticated (or logged into an application) they may have rights, authority, or authorization to perform certain operations in the application. Authorization is the mapping of an identified (or authenticated) individual to a certain resource – meaning, “you have appropriate permissions to perform the operation you are attempting”. For example, user A may be able to see confidential information that user B cannot - i.e. user A has authorization to do this, while user B does not (but both may be authenticated).
So simply put, you can most often think of authentication as being able to log into the application, and authorization, as securing parts of the application from those who are not authorized to access them. For further discussion of this topic, please see the Wikipedia link referenced.
Now, how does this relate to us? LdsAcocunt can provide authentication, but applications use the user data to enforce authorization. Spring Security can provide an abstraction for handling authentication and authorization. However, today, we will be focusing on authentication with Spring Security, including integration with LdsAccount. Authorization will be discussed in a later training.
Now that we understand some basics in terminology let’s discuss Spring Security.

14. Overcomes lack of depth in J2EE Servlet Specification
Spring Security
Spring Security is a highly customizable and pluggable enterprise authentication / authorization security framework
Provides tools for managing application access (authentication)
Rules for what users can access (by url) (authorization)
Securing methods (authorization), ...
Overcomes lack of depth in J2EE Servlet Specification
Further information can be found here:
Spring Security is a highly customizable and pluggable enterprise authentication / authorization security framework
It provides tools for managing application access (authentication)
Rules for what users can access (by url) (authorization)
Securing methods (authorization), ...
Spring Security is built for Spring specifically. It started out as Acegi security – and in 2007 was acquired by SpringSource and was rebranded as Spring Security.
It is meant to overcome the lack of depth, with regard to security, of the J2EE Servlet Specification to bring it to the level typically required by enterprise applications.
Additionally, instead of being at the application container level, Spring Security is easily transferrable across environments.
Additional information and resources about Spring Security can be found in their documentation – referenced by the given link.

15. Spring Security (authentication)
Spring comes with many pluggable authentication providers
Support provided for authenticating with:
LDAP
X.509 (Certificates)
Databases (JDBC)
JAAS
OAuth
HTTP BASIC
Form-based …
Spring Security continues the mantra of Spring, to simplify enterprise application development, by providing a number of authentication mechanisms out of the box, but also exposes the ability to plug in your own if the pre-provided offerings do not meet your needs. For instance, our LdsAccount authentication integration with Spring Security heavily utilizes the LDAP implementation. We use a pre authentication mechanism provided by Spring for our WAM integration.

16. Spring Security Authentication Manager
Basic configuration:
Native Spring in memory authentication provider configuration (applicationContext.xml)
<sec:authentication-manager>
<sec:authentication-provider ref="someAuthenticationProvider"/>
</sec:authentication-manager>
<bean id="someAuthenticationProvider" class="org.lds.whatever.SomeCustomAuthenticationProvider">
...
</bean>
<sec:authentication-manager>
<sec:authentication-provider>
<sec:user-service>
<sec:user name="billy" password="billyspassword" authorities="ROLE_USER, ROLE_ADMIN" />
<sec:user name="bob" password="bobspassword" authorities="ROLE_USER" />
</sec:user-service>
</sec:authentication-provider>
</sec:authentication-manager>
The AuthenticationManager is central to authentication services in Spring Security. It is the root of where authentication happens. This manager is declared with the authentication-manager namespace handler, and takes an authentication provider(s) specified by the authentication-provider element, which actually performs the work of determining authentication success or failure for a given individual, and of creating the user details for the successfully authenticated user. The authentication provider is totally pluggable and is the common hook into Spring Security to customize the authentication mechanism to be used. For instance, you could provide an in memory authentication provider, an LDAP authentication provider, a JDBC authentication provider, or any other number of custom authentication provider implementations and the authentication manager will use the provider specified for authenticating users. Note the examples above of a custom authentication provider and an in memory authentication provider.

17. Spring Security Web Configuration
Configure filter in web.xml
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<url-pattern>/*</url-pattern>
</filter-mapping>
There are many ways to integrate with the authentication manager, and thus the authentication provider, but, in a web application this integration typically occurs as a filter. So, in order to tie Spring Security in with your declared authentication manager, the first step is to declare the filter in web.xml as shown.

18. Spring Security Context Configuration
Configure applicationContext.xml
Please see documentation for further element and attribute information:
<sec:http security="none" pattern="/login.jsp*" />
<sec:http security="none" pattern="/errors/**" />
<sec:http>
<sec:access-denied-handler error-page="/errors/accessDenied" />
<sec:intercept-url pattern="/**" access="ROLE_ADMIN" />
<sec:form-login />
<sec:logout invalidate-session="true“ />
</sec:http>
Once the filter chain is declared it delegates to a Spring bean in the application context named “springSecurityFilterChain” which is created by the <http> namespacehandler that is not marked with security=“none”.
There are numerous attributes that can be specified for these elements to customize them and make them fit your individual application requirements. For a detailed outline of these attributes please see the Spring documentation referenced here, or use autocomplete in your IDE if your IDE can handle that sort of thing.

19. Demo
Demonstrate native Spring Security format with form authentication.
Review the configuration and show how it works.
Show accessing basic information in the home controller

20. Spring Security/LDS Account Integration
LDS Account authentication provider hooks into Spring Security
In-memory implementation
Namespace handlers simplify the configuration
As we mentioned, using the pluggability of Spring Security, the Stack provides an LdsAccount authentication provider that hooks into Spring Security, as well as an in-memory implementation for testing, and getting started quickly which also integrates with Spring Security. As part of this integration we create our own Spring namespace handlers to simplify configuration. Let's look at them
//In short, the Spring Security authentication manager takes an authentication provider that handles authentication. This is the integration point with Spring Security. Our namespace //handler creates an ldsAccountAuthenticationProvider which we register with the Spring authentication manager
You can find further documentation and explanation by going to our lds-account-ldap-spring documentation ( which can be navigated to as follows…
Also, if you are planning to use LDS Account in your application you will need to request an application account.

21. Spring Security/In-memory Authentication
In-memory authentication provides quick setup
Useful for testing
Attribute information:
In-memory authentication provides quick setup for testing and to get going, when you don’t have access to an LDS Account server for your application.
Documentation can be found at the link referenced. Let’s look at this integration and how it is both the same and different from the LDS Account integration with Spring Security.
Available LDS Account / LDAP attributes can be found in the headers document referenced, but this is probably only available within the firewall.

22. Access LdsAccountDetails
Through injection
Through static lookup
@Inject
private Provider<LdsAccountDetails> ldsAccountDetails;
public void someMethod() {
//not the get() is a call on the provider to grab the current instance
String preferredName = ldsAccountDetails.get().getPreferredName();
//… }
Ok, now we know how to authenticate, but once we authenticate, how do we get the user's LdsAccount information / attributes / details for use in our application.
A couple of ways - the right way, and the wrong way - j/k
LdsAccountDetails can be accessed through injection, or through a somewhat archaic static lookup shown above. When performing injection, we use a Provider to ensure that we
get the most up to date version of the LDS Account Details object, regardless of the scope of the bean containing it. For instance in many application, the LDS Account Details object will be created on each request. If it is injected into a singleton or bean scoped longer than request the details could get be out of date.
Also note that when going against LdsAccount you may not get all of the attributes for a user show up in the LdsAccountDetails object, depending on the data access level of your LDAP account (even in test).
LdsAccountDetails ldsAccountDetails = ((LdsAccountUser) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getLdsAccountDetails();
String preferredName = ldsAccountDetails.getPreferredName();
//…

23. Demo
Demo converting the native Spring in memory to LDS Account in memory integration
Spring Security provides in memory and LDAP authentication providers, so you might ask why we need our own LDS Account implementations. Well the reasoning is simple. If you notice the Spring in memory solution there are very limited attributes that a user can be given – such as name, password, authorities, if their account is locked or disabled. However, many Church applications need additional information in order to operate – i.e. maybe LDS Account ID, unit, callings, names, birthdate, …. The LDS Account user namespace handler allows you to specify attributes to mimic a real LDS Account user.

24. https://tech.lds.org/wiki/LDS_Account_Integration_-_Part_1#Lab_2
Lab 2

25. LDS Account (LDAP) Search
Next we will discuss the LDS Account integration with Spring Security.

26. LDS Account Search Configuration / Usage
<lds-account:ldap-server url="ldaps://gdirstage.wh.ldsglobal.net:636"
manager-dn="cn=XXXXX,ou=apps,o=lds" manager-password="XXXXX"/>
<lds-account:ldap-search />
@Inject
private LdsAccountSearch ldsAccountSearch;
public List<LdsAccountDetails> findLdapUsers(String cnValue, String snValue) {
return ldsAccountSearch.search(
SearchClause.or(
SearchClause.equals("cn", cnValue + "*"),
SearchClause.equals("sn", snValue + "*") ) ); }
In the event that you need to find information from LDS Account (LDAP) for a person other than the currently logged in user, you can do so through our LDS Account search integration. Setting up searching is really pretty easy. It requires only two namespace elements – ldap-server which creates the LDAP contextSource, and ldap-search which utilizes the contextSource to create an LdsAccountSearch bean through which searching can be performed.
Then notice that you can inject the ldsAccountSearch bean created by the ldsp-search namespace handler and use it to search.
There are two notable things that the Stack integration provides. First the results of the search are packaged up and returned in the familiar LdsAccountDetails model abstraction object. The second notable feature is the nice SearchClause interface for creating the LDAP search string.

27. LDS Account Usage
Searching format
For more info:
Native LDAP search query: (|(cn={0}*)(sn={1}*))
Abstracted search query:
SearchClause.or(
SearchClause.equals("cn", value + "*"),
SearchClause.equals("sn", value + "*") )
The above searching formats are equivalent, but the Stack abstraction makes it easy and readable to create complex searching filters. You have all of the basic LDAP operators – AND, EQUALS, OR from which to create the searches. For more detailed information about this searching interface please see the LdapSearch javadocs referenced.

28. Demo

29. Authorization with Spring Security
Next we will discuss authorization using Spring Security.

30. Authentication vs. Authorization
Review
Authentication vs. Authorization
Previously discussed authentication with Spring Security
Now focus on authorization with Spring Security
If you recall, we previously discussed that:
Authentication is verifying that a user is who they say they are
Authorization is verifying that the user has appropriate permissions to perform the operation they are attempting within the application
So when a user logs in they are authenticated, but their authorization determines which parts of the application they can access
We will now dig into authorization using Spring Security.

31. Authorization with Spring Security
Comprehensive Authorization Services
HTTP requests authorization (securing urls)
@PreAuthorize annotation
Granted authorities
Spring Security provides many feature rich ways of handling authorization. We will touch on a couple of these briefly.
Spring Security authorization operates primarily on the concept of roles – also known as granted authorities in Spring Security. In other words the authenticated user (or principal) is populated with their appropriate roles which are used to control access to parts of the application.
Please refer to the above links for further information.

32. Example of protecting urls
<sec:http security="none" pattern="/errors/accessDenied*"/>
<sec:http>
<sec:intercept-url access="hasRole('ROLE_ADMIN')" pattern="/secure/**" />
<sec:intercept-url access="isAuthenticated()" pattern="**" />
<sec:access-denied-handler error-page="/errors/accessDenied" />
</sec:http>
NOTES: Go through and discuss this line by line.
First let’s discuss protecting urls using Spring Security. Notice the intercept-url elements which define a required role (or expression) for a given url pattern. In this example, access is granted based on the evaluation of Spring EL expressions hasRole(‘ROLE_ADMIN’) and isAuthenticated(), to secure the matching pattern. You can find more information on Spring EL and what expressions are valid, in the linked to documentation.
Also, it is important to note that order matters with regard to securing urls. Spring security processes the patterns in order, until it finds a match, and then determines if the current user has appropriate authorities (i.e. the expression evaluates to true) to access that url. Accordingly, the most specific matches should come first, and the most general later. If no match is found, or, the user does not have rights to access any of the patterns that are matched, then it will go to the access denied error page specified. As such, to open up a url so that it is not secured, you would use the sec: http security=“none” declaration as shown in the first line above. This should go before the more general intercept-url patterns.

33. Fine grained authorization
Authorize Tag
Fine grained authorization
taglib prefix="sec" uri=" %>
<sec:authorize access="hasRole('ROLE_ADMIN')">
Content only visible to users who have the "admin" authority in their list of GrantedAuthority(s).
</sec:authorize>
<sec:authorize url="/secure">
Content only visible to users authorized to send requests to the "/secure" URL.
NOTES: Go through and discuss this line by line.
Spring also provides some authorize taglibraries that help in securing portions of a page based on a user’s role(s) / EL expression evaluation. An access attribute can be specified which operates similarly to the intercept-url access attribute that we just sawy. Alternatively you can specify a url, and only users authorized to send requests to that url will be able to see the content within the tag.

34. @PreAuthorize annotation
Scanning enabled with following element:
Some examples:
<sec:global-method-security pre-post-annotations="enabled"/>
@PreAuthorize("hasRole('ROLE_ADMIN')")
public void create(User newUser);
@PreAuthorize("#user.username == principal.username")
public void doSomething(User user);
Although typically web application secure based on url, or via tag in a page, it can sometimes be helpful to secure a method with annotations, even though in practice few applications take advantage of this feature. That said, Spring provides a number of annotations to aid with authorization, of which the most commonly used To enable annotations, the global-method-security element must be specified in the applicationContext.xml. If a user attempts to access a given method, but does not have the appropriate authorization (or granted authority), then an AccessDeniedException will be thrown and the method will not be executed. Accordingly you will need to have your exception handling set up to display an appropriate error page for the exception.
Notice the power of Spring EL available for determining authorization. We have seen the hasRole() expression, but in the second example, you notice that you can even access properties from a parameter being passed to the method and perform checks based on those.
NOTE: if your syntax is incorrect, you will get an IllegalArgumentException

35. Authorities Populators
MemberAuthoritiesPopulator
Adds ROLE_MEMBER authority if a member
WorkforceAuthoritiesPopulator
Adds ROLE_WORKFORCE authority if currently a Church employee
PositionsV2AuthoritiesPopulator
Adds a granted authority for each position held
Position name prepended with ROLE_
Ex. ROLE_WARD_CLERK, or ROLE_PRIMARY_TEACHER
So, now we see that urls, methods, ect. can be secured based on a role / authorities system in Spring Security. But how do we give people these roles or authorizations? We provide something called authorities populators.
By default, 3 authorities populators are automatically registered by all of our authentication provider elements (wam, ldap and in memory), unless specifically specified to exclude them.
The first, a member authorities populator, adds a granted authority of ROLE_MEMBER if the authenticated user is a member.
The second default populator added is a workforce authorities populator, which gives the authenticated user a role of ROLE_WORKFORCE, if they are currently a Church employee.
Lastly, a positions authorities populator (version 2) is added which adds a granted authority for each position the currently authenticated user holds, by appending ROLE_ to the name (or id if the name is not available) of the position as found in CDOL’s PositionType class. For instance if they were a ward clerk they would get the granted authority ROLE_WARD_CLERK added, or if they were a primary teacher they would get a ROLE_PRIMARY_WORKER granted authority added.

36. Authorities Populators
Example
<bean id="customAuthoritiesPopulator" class="org.lds.whatever.CustomAuthoritiesPopulator" />
<lds-account:authorities-populators id="authoritiesPopulators" include-defaults="false">
<lds-account:member />
<lds-account:workforce />
<lds-account:role name="ROLE_USER" />
<lds-account:custom ref="customAuthoritiesPopulator"/>
</lds-account:authorities-populators>
<lds-account:ldap authorities-populators-ref="authoritiesPopulators" />
We also provide some additional authorities populators that are not included in the defaults but that might be beneficial, such as a JPA and JDBC authorities populator which facilitate populating authorities from a database. And, if you would prefer not to have the defaults authorities populators run, you can specify the include-defaults=“false” attribute and they will be excluded. For further information about authorities populators please reference the documentation, which we will do now to show how you can also create and register your own custom authorities populator.
The authorities populators can be set on any of the stack lds-account authentication provider elements <lds-account:ldap />, <lds-account:wam /> <lds-account:in-memory />
TODO: make an issue about fail on exceptions in auth pops

37. Demo authorities-populators-demo
Demonstrate that order of securing urls is important.
Demonstrate that with authorities populators set up the defaults will give me authorities that allow me access
Then set include-defaults to false, and show that I don’t get those authorities anymore
Then maybe add a custom authorities populator and show that I get both (maybe with an EL and) if I add a custom and don’t specify include-defaults

38. The Java Stack integration with LDS Account and Spring Security rocks!
Conclusion
LDS Account rocks!
The Java Stack integration with LDS Account and Spring Security rocks!

39. Credit Where Credit is Due
Spring Security 3 – by Peter Mularien