A problem has been encountered with an Azure function that uses Microsoft authentication. The function was initially set up with the default selections from the authentication options, and worked as expected. However, after deleting the mapping and re-mapping the same app to the Azure function in the authentication setup, the authentication is no longer functioning and throws 401 unauthorized. Please share your suggestion
Related
I've already been able to get a SAML SSO up and running perfectly using this article.
However, when I try to replicate the steps using Azure as the IDP, I get the following error:
FirebaseError: Firebase: SAML Response <Issuer> mismatch. (auth/invalid-credential).
I don't know why more info isn't provided in the error, but it's left me without a lot of options for how to fix it.
I'm setting up Azure using a non-gallery Enterprise App, assigning a user to the app, and attempting to sign in on the Firebase app using the SAMLAuthProvider and signInWithPopup (as outlined in the article). Here's what the SSO configuration screens look like for both Azure and Google Cloud Identity
Configuration Screens
Azure AD is the IDP, and "Firebase" is the SP, so it looks like you have some of the values misconfigured.
The error FirebaseError: Firebase: SAML Response <Issuer> mismatch. should be referring to the Entity IDs not matching.
Start with making these 2 changes. You'll have to determine your SP Entity ID, it's likely your app's URL
https://ibb.co/rk24hKN
Background:
We have a WebAPI set up with Azure ACS and ADFS for authentication.
Accessing any WebAPI resource through the browser will redirect unauthenticated users to the ADFS login page through ACS. After successful login, the user will be redirected to return Url as setup in ACS along with security token. This works perfectly fine.
Problem:
We are developing a mobile application using the Ionic framework (http://ionicframework.com/). We want to leverage the same ACS and ADFS for authentication which we are using for WebAPI. In this process we are facing the following issues:
Issue 1:
Accessing any WebAPI resource through a mobile application (Ionic, Cordova, AngularJS) redirects the user to ACS and we get below error.
XMLHttpRequest cannot load https://{domainname}.accesscontrol.windows.net/v2/wsfederation?wa=ws…52fitem&wct=2014-10-10T14%3a24%3a34Z&whr=https%3a%2f%2f{domainname}.com. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
Hence we are not able to authenticate any user through ACS with the mobile app.
Issue 2:
Setting Return URL as empty in ACS throws the below error.
ACS90050: No reply address is configured with the relying party principal.
Steps taken so far:
-> We have enabled CORS on WebAPI.
We filed ticket with Microsoft to see if CORS can be enabled at ACS. We got below reply.
ACS does not provide a CORS solution we did research the possibilities. Unfortunately the answer is still: “No ACS does not provide a CORS solution”. That is, ACS does not give us access to the root for a standard cross-domain solution. Further, providing the token is considered HTTPOnly as manipulating the token with Javascript is inherently dangerous.
There is a sample available that may provide guidance if you wish to pursue this path although it is not recommended because of the security aspect. Download the samples found at:
Windows Azure AD Access Control (ACS) Code Samples:
https://code.msdn.microsoft.com/Windows-Azure-AD-Access-0dcde385
The sample under: C#\Webservice\ACS2WindowsPhoneSample may provide some guidance but we would not be able to assist with modifying the sample.
I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.
I am developing a web api. When I ran web api in local workstation by Visual Studio and used Fiddler or IE to consume it, all things were fine.
But if I deployed it into a remote IIS server, I get 401 error code in IE, Fiddler or client application. Even I enable Anonymous Authentication in IIS, 401 still occurs.
Could anyone give me some suggestions?
Thanks.
You can right click in the Authentification the "Anonymous Authentification" and select Edit. From there, you can assign on which credential you run the Anonymous authentification. If you set your own account, it should work (or any account that can run the web api).
In what seems like an elementary scenario, calling a GET method in my OAuth2/OWIN-protected server prevents the server from receiving the Windows identity on subsequent POSTS to the /token endpoint. What am I doing wrong?
This is a Web API service that includes an embedded OAuth2 authorization server and Microsoft's OWIN pipeline.
The authorization server provider inherits from OAuthAuthorizationServerProvider, and is installed in my Startup class. It overrides both GrantResourceOwnerCredentials (for username/password authentication) and GrantClientCredentials (for the client_credentials grant_type).
Here's the problem. If I configure the service for Windows authentication the following ensues.
Client POSTS to my /token endpoint to get a token.
Client's Windows identity arrives at the server in the GrantClientCredentials method's context parameter (specifically, context.Request.User). I can give him an appropriate token using context.Validated(id), where id is a ClaimsIdentity appropriate to his credentials.
Let's say client even POSTS again to get another token. Again, his credentials come to the server in context.Request.User. All is well.
Client does a GET to my API endpoint, including the token.
Server can inspect the claims in the token. All is still well.
Either the same client or a different client POSTs to get another token.
This time, context.Request.User arrives as null. PROBLEM!!!
If I restart the server, everything is set right. Restarting the browser does not help.
These symptoms happen whether running with IIS Express or real IIS.
The problem exists only for Windows authentication. When Anonymous authentication is turned on and a username/password duo passed, the credentials arrive safely in step 7.
FWIW, I have not yet programmed anything pertaining to a client_id or "secret". Still working on figuring that part out. If that's the problem, I'd appreciate help in how to issue a client_id and secret.