I am writing a Silverlight client and a WCF Service library solution in an Intranet environment.
As I understand it, if I set up Windows Authentication then calls to the service methods will only succeed if the caller is Authenticated in Windows and I do not need to write code to provide user credentials. I have several questions around this.
Am I correct?
I have been asked to make my application time out (as is often done with Internet applications) making the user log in again. However, I have enabled 'Integrated Windows Authentication' in advanced IE options and 'Automatic logon only in Intranet Zone' in the Security section. Effectively, now the user does not login to my application but to IE and Silverlight passes these credentials automatically to the WCF Service. I can change to 'Prompt for username and password' but then the credentials are only lost when IE is closed which I cannot do on a timeout. Even if I could I would have to close all IE opened Windows that were participating in the Intranet zone as the authentication seems to be shared amongst them.
Is it possible to impersonate another user? I have seen code to do this from a Windows application but the intellisense when using Silverlight does not seem provide the same functionality?
As far as I know you use IIS Windows Authentification. WCF services can be confugured independently and they have security based on Windows identity too, but they are a bit more difficult than traditional approach.
Your questions:
1.To disable anonymous users and allow only those users who are authentificated in Windows, you can write the following code:
<authorization>
<deny users="?"/>
</authorization>
After that user credentials will be required and passed automatically. And you don't need to send them from client's application.
If anonymous authentification is disabled by IIS, everything will work without extra code.
2.It's OK, IE and Chrome, unlike Firefox, don't require credentials every time when a user opens a web page. If you want to refresh a state of the application after timeout, you can do it without requesting credentials, for example using something of the sort of MessageBox.
3.Impersonation works only on a server side. But it's possibly to write necessary code in a WCF service and call it from a Silverlight client.
Related
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
I have two applications hosted on same IIS server. These applications have same users. Once authenticated, I am creating cookie using Angular like below:
$cookies.putObject(key, cookie)
I have kept the key same for both the applications.
Now, when I login to one application, this cookie gets created. But when I try to access second application, below code reads null.
$cookies.getObject(key)
Can I read this cookie from other application so that after login to one application, user need not to enter login credentials to other application.
Thanks.
you might be able use localstore to share data but its a huge security risk. I would not do it. I recommend using sessionstore instead och cookies when it comes to authentification. In your case it's be better to use some single signed on solution. Its a lot of them out there. OR: if you host both applications. Maybe you should merge the applications into one?
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 :)
I'm just wondering if there's any way for WPF application integrated with windows live ID?
and it's actually for windows health vault [www.healthvault.com]
so health vault is using windows live id or open id to login into their system.
and what i gonna do is, creating wpf application (instead of web application) for health vault, so all of the login form username pass and everything is handled inside the wpf application without showing/using any internet browser.
so since this's quite new for me, i hope if there's somebody ever did this before especially for health vault system that run on standalone wpf app.
alright, so that's it,
thank you in advance!
You need to use "offline" authentication, instead of "online" authentication.
Online authentication requires the user to login every time through a web browser. This is good for web applications, but not good for applications like your's.
Offline authentication lets your application access the user's HealthVault record any time it wants to. The user never has to login. To use this, the user must go through a one time connection process. This is done using a connect-request. After the user goes through this process, your application is given two authentication tokens: a person-id and a record-id. These are what your application uses to connect to the user's HealthVault record, so they should be saved to a database or somewhere similar.
This MSDN page should help: http://msdn.microsoft.com/en-us/healthvault/cc507205.aspx
The server side of the requirement is digest authentication against a custom credential store (ala a membership provider) and on the client side a silverlight application making calls to a RESTful api.
i'm looking for pointers. Out of the box it looks like Digest only works against AD. From the client side, I'm use to getting the browser to pop up a prompt for credentials --- but in this case its a sliverlight (v2) app.
Suggestions?
The authentication story, imo, is not great in Silverlight. What we typically do is rely on the fact that Silverlight requests are issued from the browser. So, they carry the cookies and headers that a browser uses (think XmlHttpRequest object, here).
What you do:
Use your provider to protect the page that Silverlight is on. The user will try to bring up the page and will get prompted for credentials.
At this point, Silverlight requests (via WebClient or anything else) will carry that authentication information. Simply protect access to assets and Silverlight will carry the authentication information to access those assets.