Is there a way to use the native WindowsIdentity/WindowsPrincipal inside of a C# application running on a corporate domain to be able to request a SAML token from the domain's ADFS server so that the C# application can then make subsequent calls to WS-Federation calls in a service provider that has been federated with the ADFS server?
Seems like we would use WIF to contact the ADFS server to get a token. Is there a way to supply a Kerberos ticket to the WIF, rather than using a username/password?
Looking at WindowsIdentity.GetCurrent() I can see that the user is logged in using kerberos, but don't see how to configure the WIF call to ADFS to use kerberos to automatically get a SAML token without a username/password set of credentials.
Does https://blogs.msdn.microsoft.com/alikl/2011/09/30/how-to-use-ad-fs-endpoints-when-developing-claims-aware-wcf-services-using-wif/ help?
You should make sure you have an endpoint enabled that can do windows integrated auth via kerberos enabled. Something like /adfs/services/trust/2005/windowstransport or /adfs/services/trust/13/windowstransport . You can check that via parsing the /adfs/services/trust/mex endpoint. Occasionally some of these endpoints are disabled by a sysadmin.
Using a kerberos ticket as the credential for the endpoint means your app needs to be running on corpnet with access to domain controllers so it can obtain a ticket for AD FS. If the app use is not required outside corpnet this might be OK for you. Else you need to consider how the app behaves/authenticates inside and outside corpnet.
Have a look at https://www.microsoft.com/en-gb/download/details.aspx?id=4451 for samples but they'll need modifying based on version of WIF you plan to use as outlined in https://learn.microsoft.com/en-us/dotnet/framework/security/guidelines-for-migrating-an-application-built-using-wif-3-5-to-wif-4-5
Lastly you should consider if its possible to use OpenID Connect and OAuth2.0 instead of WS-Federation/WS-Trust in your scenario. If yes, you should review the information at https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers
Related
I have an on-premise hosted WCF service with REST endpoint which is configured for Anonymous authentication only in IIS. I installed and configured Azure App proxy connector on the server. I am able to contact the service fine with Pass-through authentication, but struggling to authenticate from a console app when Azure AD is chosen as security mechanism. I know I could have pass-through in Azure and turn on for example windows authentication in IIS, but this is unfortunately not an option in this case.
Using a browser, I am able to access the application fine, don't even need to enter credentials, our on-premise AD is connected and synchronized with Azure AD.
I followed this walk-through despite it is not regarding application proxy, and reusing parts of code I am able to get the Access Token for my application, but when I run the http request with Authorization header I don't get the result of service operation.
Using Fiddler I can note the following:
I get http 302 (Found). I can see my Authorization header in request, and in response I get a cookie AzureAppProxyAnalyticCookie
That is followed with http 200 to login.microsoftonline.com
Example I provided link for above works fine so it is clear that I am doing something wrong. Why is Authorization header not accepted and why am I being redirected to logon page?
Thanks in advance
This is working for another service, have no idea what was wrong with the first one, but suspecting something with DNS on local server. Won't be spending more time on this, point is that I shouldn't have experienced the redirect at all, although browser handled it and managed to get me authenticated.
I am trying to better understand the OpenID Connect protocol with IdentityServer4, and am unclear on where I can find the answer to this question.
I like the idea of the Identity Server providing a Bearer Token at the end of authentication that includes claims on who the user is, and what resources they can access. However, I am a little uncomfortable in storing what Resources a user may have access to within the Identity Server environment. I would like this Authorization piece to be authored at my client application. Is there any type of callback in the OpenID callback that allows IdentityServer to call the client and request Authorization Claims from the client directly, rather than piece it together directly?
As an example, I am working on a product that will require a user to log in using either Windows Authentication, Username/Password, or a Google Account.
This client application will be hosted in a cloud environment, and will be hosted in the same domain as the Active Directory Server.
My thought was to create an Identity Server solution that is hosted internally, and to create a Client application that is hosted in the cloud.
When the user logs into the Client application, they would be redirected to the Identity Server to log in. The Identity Server would be hosted in the same domain as the Active Directory Server, so if there were Windows Credentials we could log them in automatically. Otherwise, there will be a login screen where they can enter a Username/Password, log in with Google, etc.
Once the user has logged in, the Identity Server would return a Bearer Token (a JWT probably), that has their claim information.
I can foresee this one Identity Server being used by many different Client application, because it would intrinsically allow Windows Authentication. For this reason, I am hesitant to store all of the API Resources the user can access within the Identity Server itself. My fear is that if I add a new permission to my client application (like a Report Admin claim), I would need to modify the Identity Server to include that new claim. And if 4 or 5 clients all use this Identity Server, this could get to be a bit onerous.
Instead, I would like to structure Identity Server so that when a user logs in for a particular client, Identity Server will make a callback request to the Client Application asking for the Claims that apply to that user. That way, the Client Application knows and cares about the User/Claim mappings, not the Identity Server. If I need to add a new Claim, I can do that within the Client application. If I need to map a user to a Claim, I can do that on the Client application. I don't need to do this on the Identity Server.
Is this functionality that already exists? If so, what do I need to be looking for? From what I can tell, it appears that the mapping between the User and the Resources they have access to all occur on the Identity Server.
The guide I am following is this: http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html#defining-the-api
Thank you for any guidance.
The Identity claims are not supposed to be used for Authorization, in fact Authentication and Authorization are two totally different concerns.
I'd suggest you watch this video which explains why and also provides an alternative PolicyServer that would answer your questions (great talk from the developers of IdentityServer).
Currently working on integrating an ADFS solution for the first time for a client request. Our client wants to use the federated login feature provided by their document and email management service NetDocuments, which we need to mimic and support in our own application.
We have set up a local ADFS domain and have reached the point of being able to get our saml url request https://domain/adfs/ls/wia?SAMLRequest=... but from there we cannot handle the saml response where an ADFS login page would be presented in a browser to sign in using their network credentials. What we get instead is a response string with the error "Script is disabled. Click Submit to continue" when viewed as HTML.
Once we are able to authenticate the user we would then receive a code back from NetDocuments that we could use in our app to retrieve tokens for future sign-ins.
Is it possible to programmatically authenticate a user and bypass the ADFS login screen that would be in a browser?
Some confusion here.
SAMLRequest is the SAML 2.0 protocol.
But "we would then receive a code back from NetDocuments that we could use in our app to retrieve tokens for future sign-ins" is OpenID Connect / OAuth Authorisation Code Grant flow.
You can't mix protocols.
Sounds like you need to concentrate on OpenID Connect which ADFS 4.0 supports.
The error you are getting is because SAML 2.0 is browser based and requires browser redirects to work.
Have a look at ADAL which gives you a built-in login screen and uses OpenID Connect.
I am trying to capture a SAML token that my ADFS login gives me. I need to capture the SAML by browsing to the ADFS login page, Let the user login and then when login is successful return the SAML back to the application. The application tehn calls a WCF service passing the SAML token in the header. I have a Url like :
https://adfs.mydomain/adfs/ls/IdpInitiatedSignOn.aspx?RedirectToIdentityProvider=http://adfs.mydomain/adfs/services/trust&loginToRP=https://bcjbsj.com/client-api/api/saml
I need to get this working wither in a windows application or console application. If this is not possible I can create a ASP .NET application also for testing. I have gone though many links but not able to find anything that helps.
I may be missing something here. Quite new to authentication. Any help or pointers would be helpful.
This is easily accomplished using a technique (occasionally) called JavascriptNotify. The basic idea is to display a WebBrowser control that you extend via javascript to allow callbacks to your app code once authentication is complete. You need to provide either centrally or packaged with your app an SP-STS that presents the home realm discovery page and the final jsnotify page. The rest of the UI is handled by the trusted STS's. You can optionally use Azure ACS to fill this role.
See Authenticating Users from Passive IPs in Rich Client Apps – via ACS or Access Control Service: Transitioning between Active and Passive Scenarios for what the call sequence looks like.
To understand how to add the required window.external methods, see Invoke C# code from JavaScript in a Document in a WebBrowser. Thinktecture has an example client in WPF implementing javascriptnotify with JST.
As #Thuan mentions, the other option would be to abandon WS-Federation passive authentication in favor of WS-Trust active authentication. The downside in this approach is that it is far less flexible, and you must implement the client-side UI yourself. Having written apps that implemented both WS-Trust and WS-Fed RP's, I highly recommend WS-Fed passive authentication even for desktop apps.
That endpoint is used for passive login (aka via browser) scenarios. For Windows application or console, WS-Trust is a more appropriate approach. In short, your application uses WS-Trust protocol to call ADFS to get a token that can be used to access a WCF service. Such a WCF service is called claim-based service or claim-aware service. This question has a bunch of good links: WCF, Claims, ADFS 3.0
I'm a bit confused regarding the authentication/authorization setting on the settings blade for an Web/Api App in Azure.
If I enable Azure AD authentication via the portal.
Is there any way to get hold of user information in the actual service then?
I know there is the Bearer security header, but can I extract any useful information from that?
Or is the authentication/authorization setting acting only as a proxy before the call to the service. that is, it requires valid AD credentials, but the service never have to deal with any of the details around it?
What would be the main differences between using that setting vs. creating an Web/Api App that uses Asp.NET authentication via code. e.g. its possible to set that up using the standard ASp.NET templates.
In those templates you get an OWIN app that uses an Azure AD authentication provider.
If I use the latter, is there any benefit from the authentication/authorization setting? or can I simply ignore that if the App itself has an authentication provider?
Using the authentication in the portal allows you to get some very rudimentary information about the logged-on user via the header "X-MS-CLIENT-PRINCIPAL-NAME", and you also have access to whatever claims are passed in. There's a good example here: Websites-Authentication-Authorization