API for Directory Web App

Do you have a useful link that involves the Church and the technology discussed on this site? Post your links and resources here.
Post Reply
lukeh
New Member
Posts: 18
Joined: Tue Mar 06, 2018 1:40 pm

Re: API for Directory Web App

#31

Post by lukeh »

Right. The solution I proposed above is to allow use of the API, including display or printing of information obtained via the API, but not electronic storage or forwarding of any data downloaded through the API, other than perhaps user ids, along with any external metadata (not obtained from record information) or relationships between ids needed for the custom app to function. This does not violate either of these guidelines.
ljcrapo
New Member
Posts: 5
Joined: Sun Aug 13, 2017 3:09 pm

Re: API for Directory Web App

#32

Post by ljcrapo »

russellhltn,
there is another option you're not considering here. One proposal is to give us access to an API that we can develop applications against. It is possible to restrict access to the API to only applications that have gone through an approval process. That way we are empowered to build what we need while the church retains it's control of sensitive data.
russellhltn
Community Administrator
Posts: 34384
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Re: API for Directory Web App

#33

Post by russellhltn »

ljcrapo wrote:there is another option you're not considering here. One proposal is to give us access to an API that we can develop applications against. It is possible to restrict access to the API to only applications that have gone through an approval process. That way we are empowered to build what we need while the church retains it's control of sensitive data.
Interesting. But I don't think the church has the resources needed to vet the applications for approval. The development team is very small.

I think using the in-app feedback on LDS Tools to ask for certain reports/views would be more likely.

LCR does have a "custom reports" feature (that's currently only available to the Bishop and Ward Clerk). MLS also has a custom report feature.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
devinbost
New Member
Posts: 31
Joined: Sun Aug 03, 2014 3:39 pm

Re: API for Directory Web App

#34

Post by devinbost »

The issue that I've been concerned about is related but has been more policy focused. I posted the details of the Church policy mismatch here: https://tech.lds.org/forum/viewtopic.php?f=4&t=31784

In my case, I was wondering if an application would be permitted for Church purposes in a local ward if permission was granted by every single member it affected (i.e. every single member of whose data it would involve).

Also, I wondered if the Church could require that certain security standards be required (such as dual layer encryption + SSL for transport) like is required for personally identifiable information in the educational technology industry.

However, I can understand the Church's reasons for not wanting to expose access to the data because they have no way to determine how to control the public developers' security mechanisms. What happens if one of those softwares unknowingly implements unsafe storage of the password, for example? Or uses unsafe transport? Or accidentally unsafely integrates with another service? Is the Church liable at a general level for a data privacy breech? We have probably heard what happened to Facebook. They were getting congressional hearings and all simply because a single developer abused their privileges. The Department of Defense had a recent high profile security leak as well. It doesn't take an expert to know that there are some pretty bad people who find ways to exploit Church members. What if someone broke into the home of a Church member and stole their computer and gained temporary access to member data? Of course, that could happen if someone wrote their account password on a sticky note by their computer as naive Church members sometimes do, but the Church would also need to implement a very deep defense against other types of cyber attacks against their API from efforts to circumvent the controls from members with legitimate data access who were either ill intended or had their credentials compromised perhaps unknowingly.
That is not a small feat to secure a service like that, and as a software architect, I can testify that it requires significant expertise across multiple domains of knowledge to completely secure an API to the public. It is often extremely difficult to get an API perfectly secure because software dependencies often have their own issues. The Heartbleed exploit is a well known example of that.
Theoretically, if P=NP for even some inputs (see http://www.claymath.org/millennium-prob ... NP-problem), it's actually not even possible for anything to be secured no matter how encrypted it is. Based on my years of study, I have reasonable confidence that the problem is possible to solve for at least some cases, but I haven't had the time to finish working on it yet, so I don't yet know if it applies to the integer factoring problem like would be required to break RSA encryption.

If the matter is under consideration by our general leaders, it is important for us to remember that the Lord is in charge and will inspire our leaders to make the right decision, especially when it really matters. This is not the most serious issue that they've needed to receive revelation on lately, but I promise that even then, it is not insignificant to the Lord, and He will ensure that the correct decision is made. We need to have more faith and trust in His plan, and sometimes that requires a little more long-suffering on our part. But look what He suffered through. If He can do what He did, we can be patient for our leaders to obtain the revelation they are seeking.
lukeh
New Member
Posts: 18
Joined: Tue Mar 06, 2018 1:40 pm

Re: API for Directory Web App

#35

Post by lukeh »

devinbost -- you are right, security is a hard problem in general. But you are very much over-complicating the problem. The Church already has a login system, with its own security measures in place, and to use the JSON API, you have to authenticate through that login system. That means that to create an app of your own, yes, you should encrypt the data over HTTPS, but no, you don't need to add your own login system, you just use the lds.org login system to get your session cookie. Combined with the other suggestion I have made above -- that any sites that use membership data are forbidden from transmitting that data (beyond displaying it in a UI) or storing that data (beyond storing the relationship between member ids, if necessary, for organizational purposes) -- then there is nothing that can get cracked by hackers. You would be simply building a *viewer* for membership data, with all the same security constraints and protections of lds.org, but this would give you as a local leader the ability to build a better or a different front-end to the system to meet your local organizational needs.
User avatar
johnshaw
Senior Member
Posts: 2272
Joined: Fri Jan 19, 2007 1:55 pm
Location: Syracuse, UT

Re: API for Directory Web App

#36

Post by johnshaw »

lukeh wrote:but this would give you as a local leader the ability to build a better or a different front-end to the system to meet your local organizational needs.
And there you've defined the real object to face.
“A long habit of not thinking a thing wrong, gives it a superficial appearance of being right, and raises at first a formidable outcry in defense of custom.”
― Thomas Paine, Common Sense
ljcrapo
New Member
Posts: 5
Joined: Sun Aug 13, 2017 3:09 pm

Re: API for Directory Web App

#37

Post by ljcrapo »

Here's another thing to consider:

If there are more apps available that do what we need through a secure API, I believe members will be less inclined to copy and store information in a less secure format, like a spreadsheet, and share them with people that maybe shouldn't have access anymore. People will find a way to do their job the best they know how. If the secure option isn't more useful than another less secure option. It'll be difficult to get people to not do said less secure option.

"If you want the water to stay in its course, you'll have to make a place for it to go"
- President Boyd K. Packer
lukeh
New Member
Posts: 18
Joined: Tue Mar 06, 2018 1:40 pm

Re: API for Directory Web App

#38

Post by lukeh »

Well right now, we already have local leaders having to copy and paste information from lds.org, or type it back in from printed records, because the Church pulled the plug on the CSV export option in MLS. It doesn't stop people using the information, it just makes life more difficult for everyone.
ljcrapo
New Member
Posts: 5
Joined: Sun Aug 13, 2017 3:09 pm

Re: API for Directory Web App

#39

Post by ljcrapo »

That's exactly my point.
devinbost
New Member
Posts: 31
Joined: Sun Aug 03, 2014 3:39 pm

Re: API for Directory Web App

#40

Post by devinbost »

lukeh wrote:devinbost -- you are right, security is a hard problem in general. But you are very much over-complicating the problem. The Church already has a login system, with its own security measures in place, and to use the JSON API, you have to authenticate through that login system. That means that to create an app of your own, yes, you should encrypt the data over HTTPS, but no, you don't need to add your own login system, you just use the lds.org login system to get your session cookie. Combined with the other suggestion I have made above -- that any sites that use membership data are forbidden from transmitting that data (beyond displaying it in a UI) or storing that data (beyond storing the relationship between member ids, if necessary, for organizational purposes) -- then there is nothing that can get cracked by hackers. You would be simply building a *viewer* for membership data, with all the same security constraints and protections of lds.org, but this would give you as a local leader the ability to build a better or a different front-end to the system to meet your local organizational needs.
I agree that the developer wouldn't need to create their own login system, but my point is that there would need to be controls in place to ensure that developers didn't introduce security vulnerabilities by introducing unsafe measures. For this reason, standards like OAuth 2.0 have emerged (see https://tools.ietf.org/html/rfc6749). I will quote the OAuth 2.0 RFC 6749 directly:
In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner's credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations:

o Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.

o Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.

o Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.

o Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.

o Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.
Instead of using the resource owner's credentials to access protected resources, the client obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation-specific credentials (access token)."
As mentioned in that RFC, OAuth is designed to conform with HTTP (https://tools.ietf.org/html/rfc2616).
However, since the Church can't just use any identity provider service for authentication (unless I'm mistaken), such as Google+ or Amazon, they would probably need to create their own identity provider service. The Church is not a software development company like Google or Facebook or Twitter, etc., so it would be quite a burdensome request for us to ask them to go down the path of managing, developing, and maintaining all of the software that would be required for something like this -- even if a lot of the development could be simplified if they used the latest cloud technologies, such as those offered by Amazon Web Services.
Post Reply

Return to “Links & Resources”