Advice needed for provider hosted web application - authentication and access to SharePoint document library

Question

I haven't done SharePoint 2013 development with claims so I apologize in advance if my assumptions and questions are way out in left field.
I'm trying to understand SharePoint 2013 claims authentication for a scenario that involves:
A SharePoint provided hosted (web forms) app that will pull information and assets (e.g. PDFs) from SharePoint into the web page.
It will be a VS 2012 solution with asp.net.identity feature.
Security will be set for internal users, federated external users and forms-based external users.  Based on their security and (claim type) role it will define what information and assets that can be retrieved from SharePoint
I have looked through MSDN and other sources to understand.
This one helped with my understanding 
Federated Identity for Web Applications and assumed that the general concept could be applied to forms-based identity for non-Federated external users .
What I have now:
VS 2012 solution web forms application set to Provider Host with asp.net.identity feature and its required membership tables.
I can create new users and associate claims to the new user.
I can log in with a user from the membership tables and it will take me to a default.aspx page.  I have added code to it that displays the claims associated to a user.
For POC purposes I'd like to retrieve documents that are associated to this user from the default.aspx page.
This is where I am having trouble understanding:  Is my understand correct?
Internal users
since they are internal on the network i am assuming that they would already have access to SharePoint and they would already be configured to what documents that they have available to them.
Federated external users & Forms authentication external users
it seems to me that the authentication for external users are separate from SharePoint authentication process.
changes to the configuration settings are necessary in SharePoint, IIS, web application.
I believe this is what i read.
claims processes (e.g. mappings) need to be set up in SharePoint
as long as external users are authenticated then things are ok b/c they would have claims associated to the user and the configuration in SharePoint takes are of the rest.
This statement bothers me because I think it's wrong.
So basically i'm stuck with if my understanding is correct: once a user is authenticated either by federated identity or asp.net.identity authentication that it should go to the provider hosted default.aspx page because the claim is authenticated and means
that it should have access to it and the SharePoint document library based on some claim property.  I could then write the calls to retrieve from a document library and SharePoint will know based on some claim property that the logged in user can only
access certain documents.
It just sounds too good to be true and that i'm missing something in the thought process.
Thanks in advance for taking the time to read.
greenwasabi

Answer 1

Hi GreenWasabi,
i agree this is an interesting topic to discuss,
as you can check from the article, you may check this example from the codeplex:http://claimsid.codeplex.com/
when i thinking regarding this topic, its looks like an environment with multiple of realms,
from what you understand, its correct that all the authentication is based from the provider, so for example i have a windows live ID and internal ID, then when i login windows live ID, it will be authenticated using windows live ID server.
here is the example for the webservice:
http://claimsid.codeplex.com/wikipage?title=Federated%20Identity%20for%20Web%20Services&referringTitle=Home
as i know, if you using this federated, i am not quite sure that you will need to go to the provider page literally, perhaps you can check this example if we are using azure:
http://social.technet.microsoft.com/wiki/contents/articles/22309.integrating-windows-live-id-google-and-facebook-accounts-with-sharepoint-2013-white-paper.aspx
Regards,
Aries
Microsoft Online Community Support
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.