ADFS 3.0 - Error - No strong authentication method found for the request - adfs3.0

What could be the possible reason behind the error:
No strong authentication method found for the request.
Stack:
Encountered error during federation passive request.
Protocol Name:
Saml
Relying Party:
http://testfs/adfs/services/trust
Exception details:
Microsoft.IdentityServer.RequestFailedException: No strong authentication method found for the request from http://testfs/adfs/services/trust.
at Microsoft.IdentityServer.Web.PassiveProtocolListener.CheckAuthenticationOptionsForMethods(ProtocolContext context, List`1 authMethods)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
ADFS is properly setup with Global authentication method as follows:
Extranet: Forms Authentication
Intranet: Windows Authentication
The error comes while accessing the following url:
https://testfs/adfs/ls/IdpInitiatedSignon.aspx
Note: This happens with Multi-factor authentication is enabled. The MFA module is custom made by https://adfsmfa.codeplex.com
Any sort of help will be much appreciated.

The issue happened in constructor, create event source need special permission, the services account for ADFS do not have this permission.
if (!EventLog.SourceExists(this.EventLogSource))
EventLog.CreateEventSource(this.EventLogSource, this.EventLogGroup);
I remove this 2 line and create event source in separate application. (think about at install)

Related

KeyCloak Integration with Azure ADB2C - Missing State Parameter

I’ve integrated “KeyCloak” (identity broker) with Azure ADB2C for authenticating a user.
Firstly, the user ADB2C Login user flow endpoint integrated with Keycloak and tested it, which is absolutely fine. Also, we have integrated B2C “Forgot Password” userflow endpoint with Keycloak, Upon successful Forgot Password completion in B2C, while redirecting the response back to the keycloak we are seeing an error response from the Keycloak screen as - “Missing State Parameter in Response From Identity Provider”
In the request url has Scope, Client_id, State, Response_type, Redirect_URI, nonce. But in the B2C response url contains “Client_ID”, response_type, scope and redirect_Uri.
So far, unable to find a way to handle this issue. Please suggest, if there is any approach to handle this issue either from the ADB2C or Key-Cloak.
“ADB2C- Implemented with OAuth standard authentication protocol”
Keycloak error page code:- “Missing State Parameter In Response from Identity Provider”
Thank you.
• The ‘state’ parameter is used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery attacks. In your case, the keycloak identity broker service is the authorization service while Azure AD B2C is the client.
• And since, the state parameter is missing in the response URL from Azure AD B2C, it might be the case that redirect URIs for the keycloak identity broker or the application may not be correctly configured in Azure AD B2C due to which keycloak throws an error of state parameter missing.
• Keycloak might have considered this response as a CSRF attack due to the missing state parameter and thus displayed an error whereas in Azure AD B2C, the redirection URI relating to specific keycloak page might not be correctly configured due to which though the response reached keycloak default URI but not the intended application integrated URI due to which the state parameter might be missing.
Please refer the below documentation links regarding CSRF and state parameter configuration as well as redirection URI in Azure AD B2C: -
https://datatracker.ietf.org/doc/html/rfc6749#section-10.12
https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url

The Federation Service could not authorize token issuance for caller 'DOMAIN\Account'

I am using ADFS in Windows Server 2012 with SAML 2.0 to implement SSO for an MVC application. I started to get this error which I am unable to find a way to solve. What am I doing wrong?
The Federation Service could not authorize token issuance for caller 'xxx\xxxx
'. The caller is not authorized to request a token for the relying party 'https://example.com/SampleMvcApplication/AuthServices'. Please see event 501 with the same instance id for caller identity.
Additional Data
Instance id: xyz
Relying party: https://example.com/SampleMvcApplication/AuthServices
Exception details:
Microsoft.IdentityServer.Service.IssuancePipeline.CallerAuthorizationException: MSIS5007: The caller authorization failed for caller identity System.Security.Claims.ClaimsIdentity for relying party trust https://example.com/SampleMvcApplication/AuthServices.
at System.IdentityModel.AsyncResult.End(IAsyncResult result)
at System.IdentityModel.TypedAsyncResult`1.End(IAsyncResult result)
at System.IdentityModel.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.Issue(IssueRequest issueRequest)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ProcessRequest(Message requestMessage)
User Action
Use the AD FS Management snap-in to ensure that the caller is authorized to request a token for the relying party.
In the Relying Party Trust (RPT) for this service provider (SP), take a look at the Issuance Authorization Rules tab. You'll need at least one rule to issue the claim type http://schemas.microsoft.com/authorization/claims/permit with a value of true and no claims issuing the claim type http://schemas.microsoft.com/authorization/claims/deny with a value of true, though technically I don't believe any value is needed for either. If all users are allowed to the front door of your SP, you can use the rule template under Add Rule called Permit All Users.
You need to permit that user for the relying party configured in ADFS.
ADFS management -> Relying party Trusts -> Right click your relying party -> Edit claim rules -> Issuance Authorization Rules -> Add Rule -> Permit access to all users.

Authenticating in Azure but calling web api on localhost - 401

I have an Azure mobile app authenticating on azure with FB and Twitter. I am able to login to both but when testing web api calls locally (hosted in IIS) - any controller with the Authorize attribute - returns a 401.
The alternateLoginHost is set to the Azure host and it is providing me with a token after a successful login.
I followed the instructions in the docs about setting up Local debugging with authentication.
It is using attribute based routing - config.MapHttpAttributeRoutes()
Here is my full OWIN startup class
public class OwinStartup
{
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
new MobileAppConfiguration()
.ApplyTo(config);
app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()
{
SigningKey = ConfigurationManager.AppSettings["authSigningKey"],
ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] },
ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] },
TokenHandler = config.GetAppServiceTokenHandler()
});
app.UseWebApi(config);
}
I have seen references in the documentation about either using the global http config passed in from asp.net or creating a new one - I tried referencing the GlobalConfiguration.Configuration instead of creating a new instance but it didn't help.
Is there a way to hook into the OWIN pipeline to see if the token is making it to the app service authentication module?
[EDIT] ZUMO AUTH HEADER
I am also adding the x-zumo-auth header and setting it's value to the token from the current user like this
request.headers.append('X-ZUMO-AUTH',
app.azureClient.currentUser.mobileServiceAuthenticationToken)
And I can see it in each request being made to the api. A call to the endpoint https://mysite.azurewebsites.net/.auth/me using this mechanism is returning a correct response so I know the token is valid.
[EDIT] Verified working in Azure after adding ZUMO Version Header
deployed the web api to azure and tried to call my web api endpoint and received a bad request error. It turns out it required an additional header for the version
'ZUMO-API-VERSION', '2.0.0'
I added the header and it worked.
Tried the local call again with the version header but still getting 401.
All I can assume is the OWIN middleware is not receiving the token probably due to a config problem - need some transparency into the pipeline to test some of these theories - not sure the best way to do that
Not sure where to look next in solving this.
[EDIT] OWIN Pipeline Authenticate stage Hook
OK - figured how to set up the equivalent to asp.net pipeline event handlers in OWIN - in my startup file I added this code to execute when the Authenticate stage is reached
app.Use((context, next) =>
{
return next.Invoke();
});
app.UseStageMarker(PipelineStage.Authenticate);
Added a breakpoint and when the debugger stops I can see that in the call stack
that the Azure App Service Middleware in in the pipeline
Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware
<Microsoft.Azure.Mobile.Server.Authentication.AppServiceAuthenticationOptions>
.Invoke(Microsoft.Owin.IOwinContext context)
Confirmed OWINContext.Request.Headers Contains the Correct Auth Token
Looking in the debugger the token is indeed in the Context.Request.Headers collection at the Authenticate stage of the OWIN pipeline and it has the correct value. For some reason still receiving the 401 status
I doubly checked the value I am using for the SigningKey - copied from the WEBSITE_AUTH_SIGNING_KEY value in Azure.
[EDIT] Debugging with source and exception being thrown in ValidateIdentity
AppServiceAuthenticationHandler.ValidateIdentity
Downloaded source v1.1.157.1, loaded symbols from symbolsource but those are marked as 1.0.157.1 and visual studio is complaining that the source is different than when the module was built. Because of this I cannot step through the code to see the exception that is being caught.
[EDIT]Built and Referenced v1.1.157.1 DLL - exception type now visible
In the ValidateIdentity method when it calls
options.TokenHandler.TryValidateLoginToken
The following exception is thrown
"Could not load type 'System.IdentityModel.Tokens.JwtSecurityToken'
from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'."
[EDIT] Finally found and fixed the issue
There was an issue posted on GitHub for IdentityServer having to do with a breaking change with a nuget package - going from v4 -> v5 of System.IdentityModel.TokensJwt package.
https://github.com/IdentityServer/IdentityServer3/issues/3017
I downgraded my install to v4.0.x and it fixed the exception and also fixed the 401 errors I was seeing when running locally.
All is good now
Do you have the correct app settings for authSigningKey, authAudience, and authIssuer in your web.config?
FYI -- a good writeup of the setup is here in case you haven't stumbled upon it yet: http://www.systemsabuse.com/2015/12/04/local-debugging-with-user-authentication-of-an-azure-mobile-app-service/
Is your localhost serving https traffic?
If a controller is decorated with [Authorize] it will require that the request/response occurs over https.
If you're targeting http://localhost, [Authorize] will cause a 302 to https://localhost.
This 302 can break the auth process. The solution would be to serve https locally, point your client to the appropriate port (my box uses :44300), and try it out again.
Also, make sure any relevant redirect URLs go to the https:// version of the URLs you're using.

Azure mobile service throws "Authorization has been denied for this request."

I'm using Azure mobile services with .net backend. My API controller works OK on my pc but as soon as I deploy it to Azure, Upon pinging from Postman gives "Authorization has been denied for this request." message with HttpStatusCode 401
Note that... I'm using table storage for storage instead of SQL Server and in the process removed all of Entity Framework related code. Also, None of the endpoints do not require any authentication.
Thanks.
The default authentication for mobile services is anonymous (i.e., no authentication required) when running locally, and application (i.e., at least the application key needs to be supplied).
If you're using Postman, try adding a "x-zumo-application" header to the request, with the application key (which you can get in the Azure portal) as the value. The request should work then.

DotNetOpenAuth Issue with Yahoo!

I use OpenID authentication and all of the providers have been tested and work fine when running the website from Visual Studio. I have deployed the website to the server and the Google and myOpenID work just fine but Yahoo! OpenID provider just throws this error...
The OpenID Provider issued an
assertion for an Identifier whose
discovery information did not match.
Assertion endpoint info:
ClaimedIdentifier:
https://me.yahoo.com/a/KyzgPcp9v8xRcWxFNKx357hQTxZ9P7Udww8bPkpv3oNSoogH0IXw#11950
ProviderLocalIdentifier:
https://me.yahoo.com/a/KyzgPcp9v8xRcWxFNKx357hQTxZ9P7Udww8bPkpv3oNSoogH0IXw
ProviderEndpoint:
https://open.login.yahooapis.com/openid/op/auth
OpenID version: 2.0 Service Type URIs:
Discovered endpoint info: [{
ClaimedIdentifier:
http://specs.openid.net/auth/2.0/identifier_select
ProviderLocalIdentifier:
http://specs.openid.net/auth/2.0/identifier_select
ProviderEndpoint:
https://open.login.yahooapis.com/openid/op/auth
OpenID version: 2.0 Service Type URIs:
http://specs.openid.net/auth/2.0/server
http://specs.openid.net/extensions/pape/1.0
http://openid.net/srv/ax/1.0
http://specs.openid.net/extensions/oauth/1.0
http://specs.openid.net/extensions/ui/1.0/lang-pref
http://specs.openid.net/extensions/ui/1.0/mode/popup
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
http://www.idmanagement.gov/schema/2009/05/icam/no-pii.pdf
http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
},]
If anyone has any idea why this is happening I would really appreciate it. This only occurs on the server so I can't debug it easily.
Thank You.
This suggests that your RP is performing discovery on the original identifier ("yahoo.com") instead of the claimed identifier in the assertion. Can you activate logging and include the entire surrounding log from the server in your question?