Is it possible in WIF to combine active and passive federation? We currently have multiple Silverlight clients that communicate with 1 or more WCF services. The problem is that some of these services are hosted on a different domain. This means that, when we are using passive federation, calls to those services will fail when the user is not yet logged in for that domain (WIF will try to redirect the call). So is it possible to use passive federation when logging in to the website/Silverlight client and active federation when communicating with services? And has anyone done this (with Silverlight...)?
Your scenario sounds like this: You have a website that authenticates the user using passive federation to obtain a token. You hold on to the issued token, and pass it down into your silverlight client. The silverlight client uses that token to do active federation with your backend WCF services.
The most common way I've seen to achieve this is through RIA services. I've found this article which provides a nice introduction to this. Also, the identity developer training kit has an end to end sample. Look for the one titled "Developing Identity-Driven Silverlight Applications".
You say that WIF will redirect you WCF service call. This seems to be exactly the same problem as in this StackOverflow question: Passing SAML Token to WCF service from Asp.Net, and therefore my answer to that question might apply to your situation as well.
Related
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.
I'm tried to build a new rich application and i'm having some problems designing the authentication process.
I've only two requirements :
An API needs to be available
An ADFS needs to be used to authentication
My first thoughts was to build the API and to use Angular.js for the frontend. However, I can't see how the authentication should work.
My API needs to be available though scripts. As far as I saw, the ADFS authentication always display t the webpage for the authentication process.
API are usually secured with OAuth2. We used an client id and a client secret to generate a token. But I can't have this behavior with an ADFS.
The only solution I see is to provide two authentications behavior with my application. One with the ADFS for the web access and in the web interface, add a possibility to generate a client id and a client secret associated with an user account that could be used for the API to the headless authentication.
Someone has already faced this kind of scenario?
Thanks a lot!
I assume the 'ADFS needs to be used for authentication' really means 'users should be able to use their Active Directory domain credentials to authenticate'.
If that is the case, you should take a look at Thinktecture IdentityServer. It's an OAuth2 authorization server that you can use with a Active Directory identity provider.
P.S. ADFS 3.0 that comes with Windows 2012R2 only supports the authorization code grant, which is not suitable for JavaScript apps.
Scenario: I need to configure a WPF application to send credentials from integrated security to an ADFS server and receive tokens back. I can't find guides describing in detail how to do this. The focus seems to be on web applications, web services, & WCF.
What are the steps to configure a WPF client? Is it possible to setup through a config file the same way a web app is configured?
You want to implement an Active WS-Trust scenario. Follow Lab 4 - Federation with ADFS with "active" clients" from here: http://claimsid.codeplex.com/releases/view/68061 .
If you chose to call ADFS manually to get tokens follow WIF, ADFS 2 and WCF Article Series by Dominick Baier here: http://leastprivilege.com/2010/10/14/wif-adfs-2-and-wcfpart-5-service-client-more-flexibility-with-wstrustchannelfactory/
Both of those resources have helped me to implement Active WIF Scenario.
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
I have WPF client consuming WCF service hosted in IIS. For authentication I am thinking of either certificate or user name authentication. Client calls couple of methods in WCF and passes some message.
For every call that comes to WCF, I
want to authenticate the user.
To place message in db, I have to know who is the caller, what is their username and few other properties about the user. How to pass these info[may be a small object] on every call?
This is the recommended default behavior - each call to the WCF service gets a new instance of the service, and each call is authenticated and authorized.
Just make sure not to enable things like session mode in WCF, and don't go down the path of a WCF singleton.
Just keep a regular, standard "per-call" WCF service - no issue there.
If you're on a corporate LAN, you could also think about using Windows credentials for authentication (which is the default for wsHttpBinding and netTcpBinding).
There's a really extensive WCF Security Guide which has tons of samples and how-to guides on how to set up certain scenarios of WCF security.
I would also recommend you check out The Fundamentals of WCF Security for a great intro to WCF and its security mechanisms.
A bit more advanced is the idea of Declarate WCF Security in which Juval Lowy introduces five security scenarios (that's a very worthy read!) and encapsulates them into security attributes to be applied to your service contract(s).