We have a backend service that can return a json result (Elasticsearch result) or an interactive browser web page (Kibana) based on the route. This service is gated behind an API Management service. Our developers need to be able to access the web page (Kibana). We are currently using a client certificate and we have it set to require this in our API definition. When browsing to the path in the browser, the user is prompted for the cert and the connection is made.
I would like to get rid of having to manage the certificate and instead use AAD to allow only users in a specific group to be able to access. I understand how to do this when making an API call. Is it possible to also have an experience similar to the cert where if the user is not logged in, they are prompted to log in, and then if they are in the correct group, access would be allowed?
Thanks
I imagine you want to enforce authentication at APIM level and not in Kibana. For that you'll have to handle two flows:
Initial flow, when non authenticated user requests URL, you should of check for persistent auth, possible in Cookie header and if not found - redirect user to login.microsoft.com.
Returning flow, when Azure AD redirects user back to APIM with a token, you'll need to validate that token and add it to Set-Cookie header, better encrypted.
And finally when any call is made also check and validate the cookie to see if it has expired.
Related
I have deployed an azure app to azure app service. It has no frontend part, simply an API app that does some http calls.
I have configured the Authentication/Authorization section to log anonymous requests using Azure AD.
I have registered the app in AD and connected everything together.
Here is the problem:
Upon first sign in, everything works great, I sign in and the jwt token is sent to my app and I can parse it.
However if I am already signed in and go to my app again a jwt token is not sent. However doing a GET request to /.auth/me simply returns [].
If I send a request to /.auth/refresh I get a 403 forbidden.
A bit stuck on how to proceed here. Thanks.
What is the status of your Action to take when request is not authenticated? Is it Allow anonymous or Sign-in with Azure AD?
If it is the former (allow anonymous), what you observe is expected behavior.
If it the latter - it is not expected.
When you set to "Allow anonymous" you instruct to not do anything if request is not authenticated. So, nothing happens, and you do not see any token. If you configure to "Login with ...", you will be automatically redirected if you are not authenticated.
UPDATE
Can you define "If I am already signed in.."? Also, if you configured to not allow anonymous request, every request hitting your application code will be authenticated. The app service authentication module takes care of intercepting unauthenticated calls and redirects them. Additionally /.auth/me endpoint will redirect to sign-in all unauthenticated calls, but /.auth/refresh will not.
You may also want to enable token store, which is enabled by default. The option is located directly under the list with authentication providers.
You can find more information about authentication and authorization in Azure App Service here:
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-how-to - check out the sections access user claims, retrieve tokens in app code and refresh identity provider token
I need some help with Azure API Management service.
At the moment we have a SinglePage App which is using two Backend Services (WebApi .Net Core) hosted on Azure. To Authenticate and Authrize user we are using IdentityServer (also hosted on Azure as a service) + SubscriptionService. Here IdSrv is authenticating the user and it also defines to which APIs the webapp has access. The SubscriptionService has information if the user has rights to given APIs. More or less like that.
So the flow is:
WebApp -> redirect to IdSrv endpoint -> login -> back to UI -> ask backend with user credentials (token)
Now, we want to add Azure API Management to the mix and I am struggling how to do that...
Initially we were thinking that we can hide everything including the IdentityServer behind API Management gateway, but looks like this doesn't make sense or is impossible. I found this as a helpfull reference: Generate Access Token and validate against IdentityServer4 through Azure API Management in which the second answer is quite important remark.
Based on that I think that I need to leave the Client to use IdentityServer to authenticate as this requires UI interaction but then somehow set a global policy in API Management to authorize the user using mentioned Send-Request policy. And then change backend to accept the JWT tokens from this policy? Is my thinking correct? How to implement that?
Or I should just pass the authorization-header from client request through API Management?
All those things are new for me so it could be that I missed something or messed up the terms...
The way you integrate APIM into picture may depend on goals you want to achieve with APIM. You could hide IdSrv behind APIM since there is Client credentials flow that would allow APIM to authenticate/authorize itself to an API, or you could have user authorize APIM once via Auth code grant and then store refresh tokens and use them to talk to an API. But I'm not sure that would be best since it quite a bit changes you system and forces you to solve other problems instead, like how to authenticate user to APIM. In some cases this may be a good approach, it's up to you to decide.
If you're fine with keeping IdSrv facing user, then we have APIM receiving a token with every request. You could then have a global/API policy in APIM that would send token received from user to SUbscriptionService to check user authorization to make a call) can do that with send-request policy), and either let the call pass or deny. This approach is most useful if you want to use different auth mechanism between APIM and backend, because if APIM is doing authorization work, your backend could avoid checking any user access, and instead just authorize APIM to do everything.
Check out this sample on how to authorize requests using external service: https://learn.microsoft.com/en-us/azure/api-management/policies/authorize-request-using-external-authorizer
it is quite late from asking this question but here I described how we have done that. We cover UI clients and Device clients with SSL Certification auth on APIM. In short words:
UI Client is being redirected to ID Server Loging page
APIM is doing Token validation with ID Server
APIM is doing SSL Certification verification in DB and returning back token like data for devices to pass some "device account" information.
More details can be found here:
I've scoured the api docs, as well as StackOverflow, and I've yet to find the answer to my question. And it is possible I'm misunderstanding how the system works.
Here's the scenario our client wants:
User logs into our website
At which point we authenticate the user in our system, and One Login via the api.
After the user logs into our dashboard, they can click an link and be redirected to their third party analytics app due to the fact that I've created a new session with One Login.
Here are the steps I've completed.
I've successfully received an access token via --> https://developers.onelogin.com/api-docs/1/oauth20-tokens/generate-tokens
I've successfully used the access token to generate a session login token via --> https://developers.onelogin.com/api-docs/1/users/create-session-login-token
I've successfully used the session login token to create a new session.
I'm receiving the proper cookies from One Login after making the create new session request, and - at that point - if I enter the URL onelogin.com/login, I am taken directly to the dashboard.
At this point I know I'm properly authenticated with One Login. However, I'm not sure how to directly access a third party app from a link on our website.
Thanks.
Two ways:
If the app supports SP-initiated SAML, just navigate the user to the application and it'll do the whole SAML flow- App redirects to OneLogin - OL authenticates user (because you have a session) --- redirects SAML to app
Use the launch endpoint - You can create a URL to an app by using this format: https://app.onelogin.com/launch/{app-id}. For example, you can provide a link to an app like this:
Time Reporting
Details on that endpoint can be found here: https://developers.onelogin.com/api-docs/1/embed-apps/get-apps-to-embed-for-a-user
Take note that you're probably going to want to use the optional flag that makes sure to redirect to your login page, not OL's if you've built a login facade.
We have a web service, which currently uses Basic Auth over https to authenticate user requests. We also have a website which uses the service, and a native Windows client, which also uses the web service. I've read about OAuth, and it seems like it's always used for giving or getting access to external resources, i.e. delegation, but I'm trying to understand if it's a replacement for Basic Auth.
I'm not quite sure how all the parts fit together. Do you use Basic over https to the website to retrieve a secret and then have the javascript which is making requests to the REST services authenticate to the web service using OAuth instead of Basic?
It seems that at some point the user needs to enter their username and password into a form. I'm not sure what typically happens next. Is this even a use case for OAuth?
If you have local database accounts for the users (Resource owners) then you can replace the basic authentication with the one of OAuth flow named "Resource Owner Password Credentials" flow.
It is very simple flow where you issue HTTP post to an end point specified in your HTTP server usually named /token The content-type for this HTTP Post action is x-www-form-urlencoded, so the post body will contain something like this grant_type=password&username=Taiseer&password=SuperPass
One the request is sent to the /token end point the server will validate the user credentials against your database store, and if all is valid it should generate a token (signed string) which contains all the claims for this resource owner (user). Then your client application should present this token in the Authorization header with each call to any protected end point using bearer scheme.
This token expires after certain period and you can configure this from the AuthZ server. You can read my detailed blog post Token Based Authentication to get more details.
In my case, company B (domain B) hosts a portal, which has link to my web app (domain A). If user clicks on hyperlink on the portal to my domain, he/she should be automatically logged into my app.
Existing poilicies that i cannot change:
User also has the ability to log into my domain directly, without going through the portal by supplying user id/password.
Also, existing company policy for user provisioning is that even if user log through portal of company B, they first need to have a user account with my company. Hence, the user will have account with portal company and my company.
Given these constraints, my plan for is following to provide automatic login from the portal.
When the user logs in to the portal, the portal company will generate a temporary token (UUID) and attach it as a query parameter to the hyperlink to my web app. When user clicks on my web app's hyperlink, my web app will receive a GET/POST request on the server side for a protected resource. At the server side, my web app will over https (probably two way SSL) invoke a URL on the portal's side, passing the temporary token. The portal side responds with a user id. My web app will map the user id with user's credentials and create a session for the user and allow access to the protected resource.
When the user logs out of the portal application, the portal server will make an Https request to my web app at a prespecified URL to log the user out. Since it would be two way SSL, logout url is protected.
My questions are following:
Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard. As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations. I am hoping that the temporary token described above is sort of access-token.
Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again.
Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard.
You kind of like answered your question already. That "standard-based approach" is OAuth which a Standards Track already documented by IETF in RFC 6749 and has been adopted by many software entities. If you don't implement OAuth then you are not violating the standardisation rules, you will be violating it if you claim to have implemented OAuth authorization in your system which clearly you haven't.
As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations.
Well, OAuth is a bit more complex than just generating an access token, there's an authorization grant request involved before you can request an access token. You could also expose a token refresh endpoint if the life span of the access token needs to be extended by the client. So, there's more than just access token requests involved in OAuth authorization process
I am hoping that the temporary token described above is sort of access-token
What's an access token? It is up to you how you implement an access token, the implementation details belong to you and nobody else. The only thing that you need to guarantee is that the access token represents the authorization issued to client and its scope, in other words, given an access token your system should be able to identify a client and the scope of this client...what the client is allowed to do, what resources the client is allowed to request. Be aware that OAuth defines clients which doesn't directly translate to users, it could well be a user, another system, component or app.
Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again
Absolutely, yes. This is not related to OAuth at all, it's up to the client what they do with the access token and how they store it. If your system issues a non-persistent cookie, then as soon as the user closes the browser then the browser session is destroyed and also the cookie. All modern web development technologies offer cookie management implementations such as JSP, ASP.NET, PHP, etc. So I would suggest to store the access token in a non-persistent cookie and have your authorization server inspect requests to all protected resources by checking for the authentication ticket/cookie (where the access token is) and validate the access token, if the access token (or cookie) is not present then reject the request since it is an anonymous request to a protected resource.
Hope it makes sense