LDS Account and the Java Stack
Post on 23-Mar-2016
Embed Size (px)
DESCRIPTIONLDS Account and the Java Stack. 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. Outline. LDS Account Overview History Authentication User Details - PowerPoint PPT Presentation
LDS Account and the Java Stack DisclaimerThis is a training NOT a presentation.Be prepared to learn and participate in labsPlease ask questionsPrerequisites:Basic Java knowledgeBasic Spring knowledgeA few disclaimers to get things started. 2OutlineLDS Account OverviewHistoryAuthenticationUser DetailsSpring Security OverviewAuthenticationLDS Account integrationIn memory integrationLDS Account SearchSpring 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. 3HistoryHistorically each application handled authentication as a one offTroublesome for users (many credentials to remember)User information duplicated over and over throughout the enterpriseDifficult to get user information at allScreaming for consolidation and a single, central solutionLets 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, email 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.
4LDS 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 teams documentation 5LDS 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."6What is LDS Account?LDS Account is meant to be the single source for user authentication and basic user informationLDS Account is implemented with LDAPLDS 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 didnt. 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.7LDS Account Uses LDAPLightweight Directory Access ProtocolDistributed directory of informationMuch like a databaseNot queried with SQLFor further information about the Directory structure, please see the corresponding section at: http://en.wikipedia.org/wiki/Lightweight_Directory_Access_ProtocolLDS Account = LDAPWAM = Single Sign-onSo, 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.8User DetailsLDS Account also provides user informationUser detailsUser details can be exposed through LDAP attributesWAM headersSAML attributesWhile the LDS Account teams 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.
9LDS Account User Details IntegrationThe LDS Account module acts as a Java model for LDS Account informationLdsAccountDetails.java is the abstraction layer for LDS Account user details integrationFactories generate LdsAccountDetails object for each userFactories handle the different formats in which the raw user details attributes are provide to the applicationLDAP 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 users information regardless of the authentication mechanism being used.10Lab 1https://tech.lds.org/wiki/LDS_Account_Integration_-_Part_1#Lab_1In this lab we will become a little more acquainted with the LdsAccountDetails object.11LDS Account Spring Security IntegrationNext we will discuss the LDS Account integration with Spring Security.12Authentication vs. AuthorizationAuthentication - "you are who you say you are"Identification of an individual user of the applicationCredential-based authenticationAuthorization - "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 ithttp://en.wikipedia.org/wiki/Authentication#Authentication_vs._authorizationTo 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