My scenario:
I've got a .net web application where people log into the app with forms authentication, and my forms authentication code sends certain users off to ADFS to be verified. I have multiple federations, including my own Active Directory server for internal users. So, for users that need to be sent to ADFS for authentication, I do something like this:
WSFederationAuthenticationModule instance = FederatedAuthentication.WSFederationAuthenticationModule;
SignInRequestMessage request = instance.CreateSignInRequest(Guid.NewGuid().ToString(), instance.Realm, true);
request.AuthenticationType = "urn:federation:authentication:windows";
//maybe you just don't need to specify the homerealm for ad, because there can only be one AD (integrated) trust?
//request.HomeRealm = "I-no-idea-what-to-put-here-for-AD";
Response.Redirect(request.WriteQueryString());
When you do this, you set the .HomeRealm property which populates the whr attribute for you on the query string. This should make AD FS skip the HRD (Home Realm Discovery) page. For most of my federations (remote STSs) it's very clear what value I need to put in the property, you can pull the value from the dropdown box on the HRD page itself, or you can go into the AD FS management tool and pull the value from the trust properties. For the AD trust, however, there is no value in the dropdown list (empty string), and you can't go to properties in the management console. So the question is really this: if I want to preselect the AD trust through the whr parameter, what do I set the HomeRealm Property to?
P.S. you'll see the comment there: "maybe you just don't need to specify the homerealm for ad, because there can only be one AD (integrated) trust?" I think this might be the case, but I haven't proved it yet. I will answer this later if my guess is correct.
From the code in the original question:
request.AuthenticationType = "urn:federation:authentication:windows";
That particular line didn't appear to have any effect. Also, the hope that no HomeRealm need be specified was also in vain. It turns out that you must, in fact, specify the HomeRealm. After searching google for some time, I found many statements hinting that the Active Directory trust was the same as trusting the ADFS server itself. So as a wild shot in the dark I tried putting in the URI of the ADFS server, and, much to my pleasure and surprise, this worked.
So, to be more clear, if you go to the web.config of the relying party you should have something set up similar to this:
<issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
<authority name="http://testadfs.test.com/adfs/services/trust">
<keys>
<add thumbprint="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" />
</keys>
<validIssuers>
<add name="http://testadfs.test.com/adfs/services/trust" />
</validIssuers>
</authority>
</issuerNameRegistry>
I ended up setting the value of request.HomeRealm to the value that you see there in the validIssuers and authority elements. This gave me the desired effect of causing ADFS to automatically select the Active Directory claims provider trust.
I should be clear that my ADFS server is NOT the domain controller, and yet this still works.
Related
I have creates an asp.net mvc 4 web app. I have deployed it to my dev server. (different box than my local on same domain).
Both the database and the website exists on the same server/box. I am trying to connect from my local machine which is on the same domain as the server.
I try to login on the home page and I get this error:
Login failed for user 'domain\ServerName'
I don't know where this is coming from or how to resolve it. I assume it has something to do with IIS. Any help would be appreciated.
I had this problem - It was my connection string. Somehow, it now magically now had both ;User ID={login value here};Password={password value here} and Trusted_Connection=True; key/value pairs.
You cannot use both. If you have a SQL Server login, then you don't want the Trusted_Connection=True;. If you have a trust between machines, then you don't want the ;User ID={login value here};Password={password value here} values.
It makes sense that this applies to Integrated Security=SSPI; and Integrated Security=true; too. You must leave off User ID and password when you use those as well.
(6 years late, but maybe it'll help someone else)
I'm trying to get access token of facebook client when a user logged in with asp.net's oauth template. But I couldn't acquire the access token when i tried some methods that i found on internet like;
AuthenticationResult result = OpenAuth.VerifyAuthentication("RegisterExternalLogin.aspx");
string actok = result.ExtraData["accesstoken"];
This try wasn't successfull. How can i acquire the access token?
I see noone has replied to your question even though it has been 10 days so I'll take a stab at it.
You mentioned that you are using asp.net's OAuth template. So I think you are looking at the line
AuthenticationResult result = OpenAuth.VerifyAuthentication("RegisterExternalLogin.aspx");
in the ExternalLoginCallback() action in AccountController.cs
As far as I can tell your syntax is correct. In fact also tested it out myself and it works. I guess you can try another way of accessing the same property
String myaccesstoken_value1 = result.ExtraData.Values.ToArray()[5];
That will give you the same result as result.ExtraData["accesstoken"]
If that does not work either then I would imagine that there is some problem with the authentication itself, rather than with your syntax here. I'm assuming you have VS2012 Express, so use the debugger to see what values are present in your variable 'result'. If it is empty, then it would indicate why you second statement errors out, and it would also indicate that there is a problem in the code before you get to this point.
Also keep in mind during testing that when you log into your app using OAuth providers such as Facebook, even when you log out of the website you continue to remain logged into facebook. You actually have to go to facebook.com and click logout there also (unless you write some additional code in your asp.net app to do a remote logout). I don't know if this applies to your situation, just giving you a heads up.
Please vote if this helps.
I have an ACS namespace with a WS-Federation identity provider set up. Since I'm using Visual Studio 2012, I used the Identity and Access Tool to create the relying party. The tool uses the realm and return url values that I give it when it creates the relying party (I use the Azure cloud service url where I'm deploying my project - i.e. http://myapp.cloudapp.net). There is only one rule in the rule group for my relying party after I run the tool - Pass through all claims for [Relying Party]. I tested the ACS for my app with just that one rule, and also after generating all the rules for the WS-Federation identity provider.
Regardless of the rules in the rule group, I get the error in the title of my question. My browser is redirected to ACS, however for some reason it can't find the correct relying party. I have created an ACS namespace, identity provider, and relying party in two different Azure accounts, with exactly the same result.
I've also tried publishing my project to the Azure cloud service with both http and https endpoints, and both endpoints yield the same result.
The WS-Federation identity provider's federation metadata is coming from Windows Azure Active Directory.
UPDATE
FederationConfiguration section from web.config:
<federationConfiguration>
<cookieHandler requireSsl="false" />
<wsFederation passiveRedirectEnabled="true" issuer="https://[MyNamespace].accesscontrol.windows.net/v2/wsfederation" realm="http://[MyApp].cloudapp.net/" requireHttps="false" />
</federationConfiguration>
UPDATE 2:
Still no solution. It looks like the issue stems from the fact that I set up my own ACS identity provider, and downloaded the federation metadata from Windows Azure Active Directory (WAAD) for that identity provider. That essentially chains 2 ACS instances together. When my app redirects to my ACS, it passes my app's url as the realm. Then, my ACS redirects to the identity provider, WAAD, and passes its own url as the realm. That's why the error I get back has the strange characteristic of a relying party identifier = the url of my own ACS admin portal. I'm not sure why it's not passing the realm all the way through from my app to WAAD.
Well, the answer to this was much more obscure than I had expected - I had to run the following powershell script against my CRM Online WAAD:
Connect-MsolService
Import-Module MSOnlineExtended -Force
$replyUrl = New-MsolServicePrincipalAddresses –Address "https://lefederateur.accesscontrol.windows.net/"
New-MsolServicePrincipal –ServicePrincipalNames #(“https://lefederateur.accesscontrol.windows.net/”) -DisplayName “LeFederateur ACS Namespace” -Addresses $replyUrl
This told WAAD to recognize my ACS namespace, so it wouldn't throw the error saying the ACS namespace was not a valid relying party identifier. Read the whole process here:
http://www.cloudidentity.com/blog/2012/11/07/provisioning-a-directory-tenant-as-an-identity-provider-in-an-acs-namespace/
Thanks to Azure support, I'm now past the error.
Go into the Azure ACS Management Portal. Open Relying Party Applications, and select the relying party you have configured for this app. Make sure that the field "Realm" matches exactly what you have for Realm in the web.config under <federationConfiguration><wsFederation realm=""/>.
All you require is to setup access to ACS in Active directory
After installing powershell Azure Commandlets, run the below commands as mentioned by Andrew
Connect-MsolService
Import-Module MSOnlineExtended -Force
$replyUrl = New-MsolServicePrincipalAddresses –Address "https://xxx.accesscontrol.windows.net/"
New-MsolServicePrincipal –ServicePrincipalNames #("https://xxx.accesscontrol.windows.net/") -DisplayName "xxx ACS Namespace" -Addresses $replyUrl
In case anyone else stumbles on this, double check your realm code here:
wsFederation passiveRedirectEnabled="true" issuer="must match endpoint" realm="must match audience URI " requireHttps="true"
AND
<add key="ida:Realm" value="must match audience uri" />
<add key="ida:AudienceUri" value="must match audience uri" />
my issue was a / at the end of my URI that I added instinctively - i.e. https://somuri.com/ - whereas the portal setting was https://someuri.com
Removal of the / worked.
I have only recently been looking into ACS, AAL, WAAD and I would like to avoid redirecting users to the login page of their IDP. I want to keep my users within my site and present them with a dropdown to choose who they wish to authenticate with and an area to request a username and password, then acquire token via code. Is this possible?
I have been reviewing some sample applications and produce a quick mock-up, but cant seem to get things working e.g.
_authContext = new AuthenticationContext("https://littledeadbunny.accesscontrol.windows.net");
string enteredEmailDomain = UserNameTextbox.Text.Substring(UserNameTextbox.Text.IndexOf('#') + 1);
IList<IdentityProviderDescriptor> idpdList = _authContext.GetProviders("http://littledeadbunny.com/NonInteractive");
foreach (IdentityProviderDescriptor idpd in idpdList)
{
if (String.Compare(ServiceRealmDropDownList.SelectedValue, idpd.Name, StringComparison.OrdinalIgnoreCase) == 0)
{
Credential credential;
credential = new UsernamePasswordCredential(enteredEmailDomain, UserNameTextbox.Text, PasswordTextbox.Text);
_assertionCredential = _authContext.AcquireToken("http://littledeadbunny.com/NonInteractive", idpd, credential);
return;
}
}
Using the code above, when I try to use the Windows Azure Active Directory User (admin), i get the error "Data at the root level is invalid. Line 1, position 1." where I attempt to acquiretoken.
When I use Google, I get an error "0x8010000C: No identity provider matches the requested protocol".
If there is a working sample? if I am doing something obviously wrong, I would appreciate the correction.
This is not supported for passive identity providers. IdPs like Google, Facebook, etc. don't want other people collecting credentials for them, as this leads to security issues and possible phishing attacks. They also don't support it because they need to be able to show a permission dialog (that screen that asks the user if they want to release data to you) which they can't do without the browser redirecting to them. Furthermore, Google in particular supports two-factor auth, which you couldn't replicate, and generally collecting credentials opens up whole cans of worms around other UI problems such as incorrect or forgotten passwords.
This is also generally a bad user experience, because your users are fairly likely to already be logged in to Google and have cookies there. If so, and if they've already consented to your app, they would just be silently redirected back to you. In your scenario, even if the user is already logged in they'd still have to provide a username/password.
The correct way to do these sorts of logins is to render a browser control in your app that allows the user to log in at their IdP, which is what AAL helps with.
I had the same error, executing a powerscript solved that error
PS C:\windows\system32> $replyUrl = New-MsolServicePrincipalAddresses
-Address https://mydomain.accesscontrol.windows.net/
PS C:\windows\system32> New-MsolServicePrincipal -ServicePrincipalNames
#("https://mydomain.accesscontrol.windows.net/") -DisplayName
"MyDomain Namespace" -Addresses $replyUrl
But i'm stuck anyway with a 403 permission error
If you get any further i would like to know how :)
I've set up two ASP.NET applications on a machine, their web.config files contain the same applicationName value in AspNetSqlMembershipProvider item so they share users and roles.
The problem sequence is:
user logs into application A,
opens new tab in a browser
logs into application B,
his login in application A is signed out
and vice versa.
Should I use a different approach to sharing login information between two applications?
The problem you have is because the same cookie used, for authenticate the 2 different logins.
The solution from what I understand is to give different cookie name on the different logins, so the one cookie, not overwrite the other one.
Probably the solution is on web.config.
On Config
Change the name value, to something different on your 2 apps, if you have the same domain and run on different directory/apps, or change also the domain value that used also to keep the cookie.
<authentication mode="Forms">
<forms name=".CookieSuffix" domain="yoururl.com" ... />
</authentication>
For example, on the 2 diferent web.config on your apps, place
on app 1: name=".app1"
on app 2: name=".app2"
Or
on app 1: domain="app1.yoururl.com"
on app 2: domain="app2.yoururl.com"
if you separate your apps, base on url, or even try some similar aproces.
The cookie is keep, using the cookie name on the domain name, so this is the 2 values that you must try to seperate them.
Details on Form setup can be found here:
http://msdn.microsoft.com/en-us/library/aa480476.aspx
Manual login
If you have the oportunity to make manual login the solution is on this function
FormsAuthentication.GetAuthCookie(cUserName, false, "cookiePath");
FormsAuthentication.SetAuthCookie(cUserName, false, "cookiePath");
You only need to use a diferent cookiePath, but, you must change many points on your program, and capture the process login, logout and Authenticate.
Hope this help you.
You should check out this tutorial.
Scroll down to the section titled Partitioning the User Store Into Applications. It says there that you can use the same user store for multiple applications.