I have a number of web api services created that need to get the authenticated user.
I have gotten the id server v3 working such that I can enter /core and /connect/token and my client gets a token and is passing it back to the server.
single iis server running all of the web app and web services and id server.
when I add the token authentication package I am getting an error that the well known configuration can not be found.
I am looking for what I need to change to make this work so that api calls get an authenticated identity.
I think this is a startup problem but I have my app.map() first and then the app.UseIdentityServerBearerTokenAuthentication() after.
so do I make it wait fro the first to complete ? async ? await ?
ok I am slow, I found an option to delay load the metadata and that fixed that.
now the api calls show that the user is authenticated.
Related
I want to send a request from a Controller of the ASP.NET MVC application that is deployed on the Microsoft Azure Cloud Active Directory and receive a response from the service that is still deployed on the Microsoft Azure Cloud Active Directory.
For this purpose, I downloaded an example you can see from here and customize it for myself. A detailed document of my actions is contained in the same link.
When I tested service and web applications on my azure portal, I encountered an error message in the header:
Failed to acquire token silently as no token was found in the cache.
Call method AcquireToken
Where the error occurred is the following part in my controller:
ClientCredential credential = new ClientCredential( clientId, appKey );
result = await authContext.AcquireTokenSilentAsync( todoListResourceId, credential, new UserIdentifier( userObjectID, UserIdentifierType.UniqueId ) );
clientId: Identifier of my web application installed on Azure AD (For example: c95d45dd-ba7f-41be-a995-1db604afff32)
appKey: Hidden key value of my web application in the portal
todoListResourceId: Identification of my API application installed on Azure AD (For example: 4cfebcb4-6f2e-4eeb-84f2-4220f65774ed)
userObjectID: Value returned from the following piece of code
string userObjectID = ClaimsPrincipal.Current.FindFirst( "http://schemas.microsoft.com/identity/claims/objectidentifier" ).Value;
i.e. a value for the user who is online in the browser. As stated in the document on my GitHub link, this value is not my Microsoft account that I used when logging into my azure portal, but a value for my user that I registered to my Azure Active Directory
A similar topic to this topic has been discussed and answered here before, but this answer has not solved my problem.
I've been working for days, but I haven't gotten a response from the GET, POST, PUT, DELETE methods in the service. I keep dealing with the error in the title. I'm waiting for your help.
The reason you're receiving this error is because the call acquiretokensilentasync is EXPECTED to throw that error when the cache is empty. This call is meant to be caught in a try catch. If it does throw this error it should call the acquiretokenasync call.
In addition to that it looks like you're trying to utilize the client credential flow with the acquiretokensilentasync call, which is not the right method to use per the ADAL wiki docs.
See here on how to do this properly: https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/Client-credential-flows
It looks like you're using an app id and secret, the method in particular on how to do this per the doc linked above is :
AuthenticationContext authenticationContext = new AuthenticationContext("https://login.microsoftonline.com/<tenantId>");
AuthenticationResult result = await authenticationContext.AcquireTokenAsync("https://resourceUrl", clientCredential);
More documentation specifically for the acquiretokensilentasync call can be found here : https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/AcquireTokenSilentAsync-using-a-cached-token
From the doc above :
Recommended pattern to acquire a token
Now that you have seen both AcquireTokenAsync, AcquireTokenSilentAsync, it's the right moment to
present the recommended usage pattern for calling these methods. The
idea is that you want to minimize the number of signings for the user,
and therefore you'd want to:
first try to acquire a token silently, and if this call fails you try
to get one interactively. Note that, AcquireTokenSilent does not need
to be called in the Client credentials flow (when the application
acquires token without a user, but in its own name)
Note that AcquireTokenSilent can fail for several reasons, such as the
cache does not contain a token for the user, or the token has expired
and cannot be refreshed. For these reasons, a call to
AcquireTokenAsync will usually get a token. But there are also issues
such as network problems, STS unavailability, etc., which won't be
directly solvable. You will see them in more details in the article
about best practices for Handling errors.
In addition to that, it looks like you're using the ADAL Library, I suggest to move over to the MSAL library since Microsoft is slowly moving towards utilizing the MSAL libraries and will at some point in the future (maybe far future) move off of ADAL/V1.0 endpoint. There are no current hard dates for this however. The doc on moving over from ADAL to MSAL can be found here :
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Adal-to-Msal
I have some programming experience, but only with PHP and Java enterprise systems. But now I have some ideas about a web app in my new job. Since I am new at this, I would like to share how I have done the whole API in a server, browser app and authentication with Google’s OpenID Connect (I read a lot about Oauth and OpenID Connect, most helpful source was this: https://developers.google.com/identity/protocols/OpenIDConnect).
Server: Laravel - hxxps://coolapp-api.mycompany.com
Client: Angular - hxxps://coolapp.mycompany.com
TL;DR version:
1) User goes to hxxps://coolapp.mycompany.com, gets an Angular app login page. Types in their email, clicks “Sign in with Google”;
2) The app sends the email to hxxps://coolapp-api.mycompany.com/api/sign-in. The server redirects the user to hxxps://accounts.google.com/o/oauth2/auth with all the needed parameters;
3) The user logs in to their Google account, gives my app permission if it’s their first time, and Google redirects them to my server at hxxps://coolapp-api.mycompany.com/sign-in/google/callback. The server checks everything, and if it’s all correct, it creates a JWT token and send a redirect to the client app at hxxps://coolapp.mycompany.com/login/callback?token=JWT-TOKEN
4) The client app gets the token, stores it in local storage, and sends it to the server with every API call
More detailed version:
1) User goes to hxxps://coolapp.mycompany.com, gets an Angular app login page. Types in their email, clicks “Sign in with Google”;
2) The app sends the email to hxxps://coolapp-api.mycompany.com/api/sign-in. The server creates a state token and stores it in cache, associated with the email received. Then the server creates Google’s oauth URL and sends it to the client in the response body. I tried to do it with a HTTP redirect, but Google’s server was responding with an CORS error. The Angular app reads Google’s url from the response and goes there.
3) The user logs in to their Google account, gives my app permission if it’s their first time, and Google redirects them to my server at hxxps://coolapp-api.mycompany.com/sign-in/google/callback?code=AUTHCODE&otherstuff. The server sends the code it received (and all the other needed parameters) to hxxps://accounts.google.com/o/oauth2/token. It receives a id_token with that user’s email and basic info. This app is not public, so I don’t want anyone with a Google Account logging in, only the clients whose emails I added to the server database. So now the server checks if the user’s email in the token is in the database. If it’s not, it sends the user a HTTP 401 - Unauthorized. Then the server checks the state token in it’s cache associated with the email received. If it’s equal to the one received with Google’s redirect, then the server creates another JWT token, but now signed by my server. Finally, it sends a HTTP redirect to hxxps://coolapp.mycompany.com/login/callback?token=JWT-TOKEN with the new token.
4) The client app gets the token, stores it in local storage, and sends it to the server with every API call
Some comments:
Everything is HTTPS;
I added the strictest CSP policies I could to my Laravel server and Angular client;
Currently the app only supports Google’s sign in, while it is in development. Later on I’ll add more.
I made that my server only checks if the user’s email is in the database after they logged in with google because I like that idea that a non-authorized user should have no information about anything. If I made that check before it, during the first round trip, anyone could type an email and discover if that email has an account in my system;
On the last step, when my server sends the JWT token to my client app, I tried sending the token within a cookie, but since my API and my client app have different domains, my client app couldn't read the token. Sending it in the url was the only solution I could find. I tried logging in a popular app that uses Oauth and they did it this way too.
So my question is:
Am I doing something wrong, unsecure, weird?
Thank you all very much
1) Entering an email address every time a user wants to log in is tedious. And it's not needed if the user is already logged in at Google. The user should just click the "Log in with Google" button and get logged in without entering anything. The state parameter can be a random string - not related to the user's email in any way.
2) If you want your backend to process the redirect from Google (using the auth code flow - the backend has the client role in OAuth2 terms), the backend should also initiate a redirect to Google - not by sending data containing the redirect URL. To achieve it, after clicking the "Log in with Google" button, perform a whole page navigation (instead of an XHR request) to /api/sign-in and if the backend returns HTTP 302, the browser will correctly redirect to Google.
3) You should perform request validation (the state parameter) before getting tokens and checking whether the user exist.
On error (access denied), you can consider redirecting the user to an error page with error details instead of returning HTTP 401, since the HTTP code will cause a generic error screen to be displayed to the user. If you want to keep using HTTP codes, I think HTTP 403 Forbidden would be more appropriate.
4) Consider using sessionStorage instead of the localStorage. The sessionStorage gets cleared after closing a browser/tab and it's not shared among tabs. It makes it safer and it allows users to use different identity in different browser tabs.
The tokens your backend issues, is their validity time limited? Is the user required to get a new token after some (short) time period? If not, valid token vales may stay in the localStorage and browser's page history, which can be a security problem.
You can consider using your own OAuth2 auth server (such as RedHat Keycloak) which would accept Google (and later some other providers) for authentication and it would also issue access tokens accepted by your backend.
So I'm trying to do google oauth to get a refresh token for my users (not actually using google oauth to save the user). I had everything working when I used the client side OAuth for google api but they don't provide a refresh token when you do that handshake, only an access_token. I need a persisted refresh_token since I'm going to be making a lot of requests to the users google calendars.
So I set up omniauth on my rails server to make the flow go like this:
user clicks authenticate with google (client side) -->
popup screen goes to backend server (localhost:3001/users/auth/google_oauth2) -->
backend rails server redirects to google for authentication -->
they authenticate with google and get redirected to backend server's callback (localhost:3001/users/auth/google_oauth2/callback) -->
backend server saves token for appropriate user and then redirects back to client side app on localhost:3000 (nothing needs to be done on client, just need the token saved on my server for future use)
I do however need to know that the authentication was successful so I can dispatch appropriate actions in react/redux. In redux-auth they check for the access_token inside the popup.location URI. Problem is when I use this server side popup flow I get this nasty http/https error:
(original image: http://imgur.com/v5NgIGr)
If instead of redirecting back to the client I just redirect to a view in my backend server I could then have a script on that page that just does window.close() which works but seems hacky to me. Another potential solution I was thinking was to try and use the window.postMessage api but I don't know if that has great browser support/also seems hacky. I could emit a message to the other window (the main client app) from the popup saying the oauth was successful so my react code and do whatever it needs to do.
I feel like I'm just approaching this whole flow completely wrong or I'm missing something obvious.
I also feel like if I just had HTTPS on everything it would all work since before when it was 100% client side the popup worked beautifully and I didn't get this SecurityError. I spent some time figuring out how to get my webpack dev server using https and tried doing the same with rails (think I did something wrong on the rails side) but it was still not working. Also feel like I shouldn't need to force HTTPS on all my development servers in order to get it working...
If anyone has any thoughts or could give me some direction that would be much appreciated!!
You are approaching this the wrong way. Google's authentication and their APIs do have confusing documentation. I was also stuck with similar situation and after spending considerable time, I found the right way to do this.
From your question, I believe this seems like the relevant link: https://developers.google.com/identity/sign-in/web/server-side-flow
And following it, here is how your flow should look like:
To map it on your problem, this is what you will do:
user clicks authenticate with google (client side)
Client requests Google for authorization that includes your scopes
and receives a one time authorization code.
Client Sends this authorization code to your ruby server.
Ruby server uses the authorization code to exchange it with access_token and persisted refresh_token which you shall use in your subsequent requests to google apis.
Hope it helps.
How should I access the share point web services in iOS which need to be authenticated by TMG. When I invoke login request it returns login HTML template in response as shown below
Can we authenticate TMG firewall somehow in iOS. I am not expecting whole source but any help, references will be appreciated.
Finally we got solution to this stuff. By requesting site info using GetWeb method like
"SOAPAction" : "http:\schemas.microsoft.com\sharepoint\soap\GetWeb"
along with a username, password we received cookies. Then passing these cookies to next share point services we received response and resolved above TMG auth issue.
I use SignalR 1.0.1 as a chat core for ASP.NET MVC3 application. Using IIS 7.5
There are two methods in MVC controller which provides access to chat views:
1. First method is public, allowing anonymous users to chat - no authorization.
2. Access to second method is restricted with [Authorize] attribute, for domain users - chat agents.
There is no explicitly specified authorization in the Hub.
For this scenario I involved both Windows and Anonymous authentication on IIS.
I also implemented custom Role Provider, which operates only in memory - not persisting anything to database.
What happens is that using '[Authorize]' attribute in controller method leads to responsing 500 from Hub, both when call is coming from authorized view, and the anonymous one:
Request (send is Hub method for sending messages):
http://localhost:8101/signalr/send?transport=serverSentEvents&connectionToken=VIXEZzWQSn5SNlA8RUy4iaOPDFdvuPBjMvFBiG2FLfvfxF347XHwtapsEV5ndU4OEI0Xb64W2ZRXTqwBiL2CXg2_JlTaTJ2RnVOj4bjvx6tQaYhAqTaXs9k2853GYqzd0
Response:
The connection id is in the incorrect format.
Server stack trace:
at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId(HostContext context, String connectionToken)
at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(HostContext context)
at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke(IDictionary2 environment)
at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke(IDictionary2 environment)
at Microsoft.Owin.Host.SystemWeb.OwinCallContext.Execute()
at Microsoft.Owin.Host.SystemWeb.OwinHttpHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object extraData)<br/><br/>
But notice, that connecting to Hub works fine, returns 200 OK:
http://localhost:8101/signalr/connect?transport=serverSentEvents&connectionToken=dYOwFxa1mkgdpzw-jitRpWq9oxRlrTet8U_dAzWjFQEdGNJfVXeG7Op0NZZwvznxeNdJCuPT75CKzQqI9HRPThV3uEDt-Z2qtIl9E02gF481&connectionData=%5B%7B%22name%22%3A%22chathub%22%7D%5D&tid=9
I found little similiar thread here on stackoverflow:
signalr The connection id is in the incorrect format
from which I understand, that when invoking my Send method, the Hub is processing request with Identity different than the one used to connect to Hub, OR Hub's GetConnectionId finds, that user is actually not authorized - but how it checks that assumption, when there is no authorization specified on the Hub itself?
Can someone put some light on this?
Thanks in advance :)
SignalR signs both your connection id and your Identity together in order to create a new connectionToken every time you start a new connection. This connectionToken is then sent to the SignalR client as part of the negotiate response.
Every time you make a request to SignalR, whether it be a connect, reconnect, or send request, SignalR verifies that your connectionToken matches both your client's connection id AND Identity.
The connectionToken is essentially a CSRF token used in order to prevent attackers running third-party websites from surreptitiously making SignalR requests on behalf of shared clients. Obviously this doesn't help if you've enabled SignalR's cross-domain support, but the connectionToken still works the same in this case.
Taylor's answer was correct. You should stop and then start your SignalR connection when your client's Identity changes. This will force a new negotiate request which will give your client a new connection id with a new connectionToken signed with your client's updated Identity.
P.S. The server-sent events connect request isn't failing because it was established before your client's Identity was changed. The connectionToken is only checked at the request is received, but server-sent events keeps the response open indefinitely.
That's all true what you said and it actually takes place in my issue.
But I also found the the root cause:
One of main assumptions during design was to allow both anonymous users to use the chat without need to sign-in and the back-end users (agents) to sign-in to restricted area of chat using their Windows credentials.
So on the IIS manager I enabled both Anonymous authentication (allowing anonymous users to use the chat) and the Windows authentication (allowing agents to access using their Windows credentials).
MVC application is configured to use Windows authentication - the [Authorize] attribute mentioned in question, but only to restrict access for agent's view of chat.
What actually happens with above configuration is:
1. When client (agent) requests restricted View (let's say it's /Chat/Agent) the [Authorize] attribute initializes authentication (Windows)
2. Client-side Javascript requests Negotiate, what generates connectionId and binds it with client's Windows Identity
3. Here is the tricky part: Because Hub not uses any authentication explicitly, calling send method does not result in any authentication request - IIS Anonymous authentication takes precedency before Windows authentication, and send request is sent with anonymous Identity - but in Hub actual connectionId is related to Identity passed in point 2.
This scenario leads to situation you described - connect is called with different Identity than send and Hub returns The connection id is in the incorrect format.