I have an interesting situation that I haven't been able to crack. Here is the environment that my Silverlight application runs in.
We have a SharePoint 2010 intranet that is the main host for the application. On a web part page, we have a Silverlight web part that contains the application. We use the Client Object Model to deduce who the logged in SharePoint user is. The users of this application access the SharePoint site OUTSIDE of the AD domain that they use to login; meaning they have an AD account, but their computers are part of various domains. The Silverlight application makes calls to a WCF service over https via SOAP protocol.
The question is, how do I secure the services so that the only valid requestor is the Silverlight application when being called from inside the context of a logged in SharePoint user?
Each end-user has an AD account that is created for them. The SharePoint site is an extranet that requires each user to login using their AD credentials. However, no end-user is accessing a site from a computer that is part of the domain.
I've attempted using Windows Authentication, but we have a requirement that the user must not be prompted to login (to the web services) after they have already logged into SharePoint. I've attempted using the Client Object Model to "pass" authentication/credentials to the service, but no luck there.
We have to disable Anonymous Authentication before we go to live, so I've got to figure out a way to secure the services but not make the users login a 2nd time inside the application.
out of the box you cant, silverlight cant delegate to any external service for security reasons. What you can do is to secure your WCF channel via some other method (certificate based for example) and send through the current username manually. On the SharePoint end you can then impersonate the user.
It will be quite a fiddly thing to get going though :)
Related
I have a WPF desktop using the WebView2 control, and it works quite nicely. The problem I am trying to solve is handling the authentication for users who find the repeated prompts when accessing our SharePoint Online (SPO) site within the WebView2 control annoying. I am not looking to access Graph API or the SPO API, just allow the user to navigate to our SPO site without login prompts. Our on-prem AD synchronizes with Azure AD.
A couple of applications I've developed:
An Office add-in using SSO with delegated permission and signed off by our admin so that users do not log in
A console app that has application permission to update all calendars in our organization via the EWS API, protected with Azure AD certificate authorization, although it initially used a secret
That said, how can I set up the app authorization so that my desktop WPF app can allow the users to access SPO without prompts?
According to your scenario, you can try the following things in your web view control such that you will no longer receive authentication prompts for Sharepoint online login.
• You trying to access SPO site within web view control, so you need to allow authentication for both the http clients, i.e., Windows store clients(classic)[System.Net.Http.HttpClient] and HTTP clients[Windows.Web.Http.HttpClient] connected to web view controls. You can do so by adding the new one in your code as below: -
var filter = new HttpBaseProtocolFilter();
filter.ServerCredential = new Windows.Security.Credentials.PasswordCredential("http://website","login","password");
Windows.Web.Http.HttpClient client2 = new
Windows.Web.Http.HttpClient(filter);
var response = await client2.GetAsync(new Uri("http://website"));
WebView.Source = new Uri("http://website");
• In this code, change the “login” and “password” to the credentials you want to use to login in the SPO site. Also, change the “http://website” to the SPO website and set the ‘enterpriseAuthentication’ parameter to off.
• Also, you can use the ‘’TodoListService” Service app for maintaining an in-memory collection of to-do-items for each authenticated user for login purposes.
Please refer the below links for more reference: -
providing domain/user credentials to webview control
https://learn.microsoft.com/en-us/previous-versions/windows/hh465283(v=win.10)?redirectedfrom=MSDN
https://learn.microsoft.com/en-us/samples/azure-samples/active-directory-dotnet-native-aspnetcore-v2/1-desktop-app-calls-web-api/
This way, hopefully the SPO site can be accessed through desktop WPF app without authentication prompts.
Thanking you,
I have a requirement to create an admin UI where I need to list all users registered on IdentityServer to start assigning permissions and roles. This application internally uses PolicyServer, but as a superadmin user, I would need to see all users registered on IdentityServer. Here IdentityServer is responsible for authentication and the other application that uses PolicyServer is responsible for the authorization.
Which is the correct way to proceed:
1- This admin UI application should be connected to the same database that IdentityServer uses to get all the users?
2 Or should I need to extend IdentityServer on this way?:
http://docs.identityserver.io/en/latest/topics/add_apis.html
I followed this issue here:
IdentityServer/IdentityServer3#2607
but still, it is not clear for me how to proceed on the question above.
Well, the users database is usually provided by ASP.NET Identity, not so Identity Server.
I had the same issue and I went on to develop the admin Web app in the same host as Identity Server, thus using the database connection to get to the users (and the API resources, clients, etc.).
I argue that this is the simplest way to achieve what you want. And still allows you to provide a complete API on your Identity Server for external apps. I also did that (for scenarios where client apps are allowed to view/edit the user profile, for example). The API was built using plain ASP.NET Core MVC.
New to Azure AD... So please don't be too harsh if this is off target. :-)
Technology Stack - Latest Angular 2 with C# Middle tier and latest .Net Framework.
Ideally, What we want to do is use Azure AD B2C to store user credentials and to do the authentication - but we want our 'own' forms on our site to do the login Forms capture and logging - then pass the credentials through an API (REST?) Call (using MS Graph SDK?) to Azure AD B2C and then check the call return for the Authorization content message.
Couple of reasons - control of the application flow, Logging and the "flickering of the URL" (i.e. going from our site URL to login.microsoft... URL and then back to our sites URL).
Is this doable without doing a hack?
Thank you in advance for your help and patience!
You are looking for the "Resource Owner Password Credentials".
This is not currently supported for Azure AD B2C, but you can give user feedback to the B2C team that you want this through the Azure Feedback Forum: Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
You should also see updates at that location if and when they implement this feature.
The resource owner password credentials flow is now in preview.
In Azure Active Directory (Azure AD) B2C, the following options are
supported:
Native Client: User interaction during authentication happens when
code runs on a user-side device. The device can be a mobile
application that's running in a native operating system, such as
Android, or running in a browser, such as JavaScript.
Public client flow: Only user credentials, gathered by an application, are sent in
the API call. The credentials of the application are not sent.
Add new claims: The ID token contents can be changed to add new claims.
The following flows are not supported:
Server-to-server: The identity protection system needs a reliable IP
address gathered from the caller (the native client) as part of the
interaction. In a server-side API call, only the server’s IP address
is used. If a dynamic threshold of failed authentications is exceeded,
the identity protection system may identify a repeated IP address as
an attacker.
Confidential client flow: The application client ID is
validated, but the application secret is not validated.
From here.
Note that one disadvantage of doing what you're requesting is precisely that you can do "login forms capture and logging", so your application has a chance to see the credentials and perhaps take copies of them; thus your users have to trust you to behave.
The normal web-based flow means that your application doesn't need to be trusted; it never even sees the password at all.
We have a bit of a dilemma that we are running into with a couple applications that are trying to read a given users email without user interaction to authorize. The key to this approach is that we want no user interaction, and want to load the client server application with the proper JSON credentials downloaded from the Google Developer Console.
I have this approach working for programs where we create a service account in the Developer Console, and then delegate domain wide authority to that account with the proper scope access. However what we are hoping is that we don't have to delegate domain wide authority, and just read the users email who created this developer console project. I have tried many different types of solutions for this, but always run into the same limitation that I have to grant domain wide access.
What I am wondering is if there is any way to gain access to a single users mailbox using a server to server type approach and not have to grant domain wide access?
I appreciate your help with this issue!
There is no supported authorization flow for what you want to do. You must either use a service account that has been delegated domain-wide authority, or you must use a 3LO flow that involves user consent.
It seems you're looking for OAuth for Server to Server Application. You will also be using a service account. But, granting of domain-wide authority for service accounts is an optional thing. You don't have to enable it if you don't want to.
To support server-to-server interactions, first create a service
account for your project in the Developers Console. If you want to
access user data for users in your Google Apps domain, then delegate
domain-wide access to the service account.
Then, your application prepares to make authorized API calls by using
the service account's credentials to request an access token from the
OAuth 2.0 auth server.
Finally, your application can use the access token to call Google
APIs.
I have spent many hours trying to get my Silverlight Business application to run on Azure. My findings so far (open to correction)
Asp net authentication works with a Silverlight web application but not if Ria services is added. This is because Azure only allows one form of authentication per hosting and WCF will not work if the authentication mode is not Anonymous. This mean using WebContext is out of the question.
For the same reason passive federated claims authentication (either OpenID or custom STS) will not work with Ria services.
There is some good stuff in the Identity Training Kit. Active federated claims should allow a login popup to by used. Again there is an example in the kit. I initially didn't look at the "Out of Browser" example until I realised that it should work In Browser as well. I created a custom STS which the Web app called successfully, but I got "service not found" - I assume on the return leg.
I have now decided to pull the plug on all this as I need to get my application up and running. The Silverlight client already communicates with my database via Ria Services - why do I need to create extra pipelines when the authentication data is going to be in the same database? Would security be comprimised by simply checking a user name and password against my database? Would the System.ServiceModel.DomainServices.Client.ApplicationServices namespace be useful in this?
Second statement in your list is not accurate. You can use claims based identity with Ria Services. See here:
http://blogs.msdn.com/b/eugeniop/archive/2009/11/22/updated-ria-and-wif-samples.aspx
http://blogs.msdn.com/b/eugeniop/archive/2009/11/25/ria-services-and-wif-part-ii.aspx