My MVC 4 application (https://testapp.com) with WIF and windows authentication is on Domain A and my ADFS and users are on domain B.
Requirement: Users in Domain B will browse my application https://testapp.com which is hosted in Domain A and my application should use their local windows user creds and redirect to the ADFS in Domain B.
I believe I dont require a AD cross Domain trust between A and B and that is what ADFS and SAML authentication is meant for.
I dont see such much materials for reference in such scenarios also. Kindly help understand how to configure such an MVC application in Domain A.
You need to establish a trust between your MVC4 application and your ADFS. In ADFS lingo this is called "Relying Party". You will need to have an endpoint in your application that accepts a HTTP POST message and processes the payload generated by ADFS.
I had to recreate these a long time ago but you can spare the pain. There are more options available -
http://saml2.codeplex.com/ (open source)
http://www.componentspace.com/Products/SMLv20.aspx
Configuring ADFS can be tricky but there are lot of guides out there.
Related
I have a confusion in while doing development. I am working on .NET 5 Web API in which I have implemented JWT authentication. Then I got to know that, client application(it entire different project owned by other team in my same organization) is configured using Windows AD or SSO, not fully sure though. But still client application won't be sending userid and password in a post request which I have in my AuthController. In this case, how my APIs requests will be authenticated to check if the client has access to it or not.
Any guidance on this would be helpful. Thanks in advance.
I have a working c#/dotnet Windows desktop application that does its work by hitting various web services in my web application. When the desktop application starts up, it prompts the user for username / password and then hits my login web service, which returns a session token.
I have a large-org customer with many users. That customer wants to provide authentication / authorization for my combined desktop / web application directly from their domain controller. They want single signon, so my desktop app doesn't prompt their users for usernames and passwords.
How can my desktop application retrieve a usable authentication / authorization token from Windows (maybe from the user's Security Principal object)? How can my web application validate that token so it can trust the desktop application and send it a session token?
(My web application runs in my environment, not in the customer's domain.)
With pure-web-app customers I do this successfully with SAML2 and Active Directory / Federation Services. The SAML2 dance gets my user's browser to POST a request to the customer's AD/FS server, which then POSTs a signed response back to my web app.
But I can't figure out how to do it cleanly from a desktop application. Any wisdom?
You can check this samples in github (by jelledruyts): Modern claims-based identity scenarios for .NET developers
It has samples of authentication and authorization using Azure Active Directory and/or Windows Server Active Directory Federation Services.
I suggest read this article Digital Identity for .NET Applications. It's a little old but is a good overview/review.
Tokens come in many different formats. For today’s .NET applications,
however, three kinds of tokens are most important. They are the
following:
User name/password token—This very simple token contains only two
claims: the name of some subject and that subject’s password.
Kerberos ticket—More complex than a user name/password token, a
ticket includes a subject’s name, the name of the subject’s Windows
domain, and other information. Kerberos tickets that are issued by
Active Directory also include an extension that contains security
identifiers (SIDs) that identify the subject and the groups to which
this subject belongs.
SAML token—The Security Assertion Markup
Language (SAML) is an XML-based language that is owned by the OASIS
multivendor standards group. Unlike the other token types that are
described here, a SAML token doesn’t have a fixed set of claims
defined for it. Instead, this kind of token can contain any claims
that its creator chooses.
As soon as the claims are available, they can be used by Windows, the
application, or both. The most common uses of claims include the
following:
Authenticating the user(...)
Making an authorization decision(...)
Learning about this user(...)
Kind of Authentication:
Domain Based Authentication (eg Kerberos tickets):
A domain-based application accepts only a single token format with a
fixed set of claims. One common example is a Windows application that
accepts only Kerberos tickets. This kind of application is easy to
create, and it works well inside a single Windows domain. The problem
is that this simplistic approach to digital identity is no longer
sufficient for many applications
Claim Based Authentication (eg. SAML tokens):
Unlike a domain-based application, a claims-based application can
potentially accept multiple token formats with varying sets of claims.
The token formats and claim sets that this application accepts are
determined by the application itself.
Identity Technologies
Active Directory (AD) Domain Services (full-featured directory service, token source for Kerbero tickets, etc)
Active Directory Federation Services (ADFS) (support for claims-based applications, token source for SAML tokens
Windows CardSpace
Active Directory Lightweight Directory Services (subset of AD services)
Identity Life-Cycle Manager (ILM) (synchronization between different identity stores)
Windows Authorization Manager (tools for RBAC - role-based access control)
Active Directory Rights-Management Services (RMS)
Because AD Domain Services implements Kerberos, the default token in a
Windows environment is a Kerberos ticket. To use this default, an
ASP.NET application specifies Windows Integrated Authentication, while
a WCF application uses an appropriate binding, such as NetTcpBinding.
In either case, the following figure illustrates how a Windows
application with clients in the same domain might use a Kerberos
ticket and AD Domain Services
First versions of AD FS only support SAML with web clients.
ADFS 1.0, supports only browser clients—a restriction that’s scheduled
to change in the technology’s next release.
Hope it helps.
I should preface this with the fact that I've never done this, so I can't give you exact code, but I can point you in the right direction.
You should be able to do this with ADFS and Windows Integrated Authorization (WIA). In a "pure web app", the browser sends the credentials of the currently-logged-on user during the authorization step. In your case, your desktop app needs to do everything that the browser would normally do. Either way, the setup on the web service side should be exactly the same.
In C# with HttpClient, this is the important part:
var httpClient = new HttpClient(new HttpClientHandler()
{
UseDefaultCredentials = true
});
Then, whenever your httpClient sends a request that is challenged with a 401 response, it will automatically resend the request with the user's Windows credentials. This is exactly what a web browser would do. So use that when you get the token.
You may have to send a user agent string in the request, since ADFS seems to limit WIA to certain agents.
Once you have a token, then use the token in your requests to the web service.
The key is that you're replicating what a browser would do. So if you have trouble setting up what the HTTP requests should look like, then access a GET request in your API from a browser and use the browser's dev tools to inspect exactly what the traffic looks like, and use that information to replicate the same request in your code.
I've managed to setup two virtual machines in my local windows 7 laptop. Both of them are Windows server 2008 R2. One acts as Active Directory Domain controller and also as Active Directory Federation Services, and one other as the web app server. This second one is where I've set up my claims aware asp.net mvc web application and I also plan to setup ThinkTecture Identity Server later as my way to authenticate against custom username and password outside AD.
I've successfully implemented the installation and configuration needed for connecting our ASP.NET MVC apps through ADFS. They include :
Configure first server as Domain Controller and add domain account store (add user as testing -> this user belongs to Domain Users Group).
Configure first server also as active directory federation services.
configure relying party trust identifier from federation metadata generated from FedUtil.exe in second server.
Configure group claim mapping and assign Domain Users to this group.
Configure web apps server to be claims aware agent.
The one that's always troubled me is that every time I access my apps, it successfully prompts login dialog box. Once I enter My AD account and password, it always gives me the following error message : "There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Reference number: c558ed55-b203-42cc-b6bd-3d66bddb96cd".
Any idea from you guys how to get this to work?? Any suggestion and ideas will be highly appreciated.
Have you looked in the event log?
Open Event Viewer > Go to Applications and Services Logs > AD FS 2.0
You'll see an list of errors which should give you some more guidance.
If you see the ADFS login screen, you can get to ADFS so I suspect it's something to do with your RP configuration.
Just to check - you are using ADFS 2.0 which you downloaded?
I have an application in domain A and would like it to use domain B credentials to access domain B content. These domains have no trust. Is it possible to challenge a user in domain A, and get them to input credentials for domain B? Then use these credentials to authenticate in domain B. Meaning we bypass domain A's Kerberos Distribution Center (KDC).
I have no problem getting this to work inside a single domain, meaning impersonating the challenged user and maintaining an impersonation level of delegation. However, MS documentation says that the application in domain A will use its KDC to issue a ticket (or fail to issue the ticket) and this will cause my service in domain B to drop to NTLM.
Is it possible to force my service in domain A to use domain B's KDS? I could be way off base here.
The architecture is Microsoft WCF services.
Thanks,
Kevin
The quick answer is NO you cannot pass credentials across domains without the 2 domains having some level of trust.
However, I got around this by using asp.net forms authentication. When the users credentials from domain A fail I effectively get them to input the credentials from domain B and redirect them to an "Authentication" MVC controller that scrapes the user identity and then encrypts it in a Asp.Net forms authentication cookie. This is returned in the response header. All subsequent requests are made with this cookie and I check for the the authenticated user in the session cookie. Not as elegant as delegation but it works.
I was hoping that someone could confirm my understanding (or lack thereof!) of ADFS with respect to WCF.
I've even drawn a pretty diagram.
"Bob" uses a web app, which is hosted on Client's domains. Client authenticates Bob via AD. However the web app uses a WCF service developed and hosted on Supplier.
There has been trust established between Client and Supplier.
My question - when the Web App uses the WCF Service, I would like the WCF service to re-authenticate "Bob", and the WCF service can then use the Claims returned by the ADFS server which is on the client.
Is this picture right?
Almost. Move the arrows between the Web service and ADFS (the IP-STS) to be between the Web app and ADFS. Then, the "Bob" that it will send to the Web service is a token that is signed by ADFS containing claims about Bob. The Web service will check this signature, and, if it matches, the claims will be considered trustworthy.
Typically, for cross orgranizational use cases like this, the supplier would also have an STS (an RP-STS). Trust would be established between the STSs. Then, local applications (e.g., the Web app and service in this drawing) only need to trust their local STS. This avoids a fully connected graph of trust relationships.
HTH!