We currently have a website that is setup to use SSO through Azure AD. it is configured to with SAML.
Yet, we have third application that needs to connect to this website using specific email and password.
This application can do any default connection that POSTMAN can do.
What I do notice is that web all cookies are removed from the browser. the website allows me to enter
the email address and password.
I am trying to configure POSTMAN to test login to this website. And using the POSTMAN configuration i will be able to configure the application.
Any Guidance is greatly appreciated. Thank you!
I have try configuring post using HTTPS POST BASIC Authentication. Not sure if this correct manner as I am not postman expert nor have attempted such authentication method before.
Our expectation is the POSTMAN could login into the website and create a cookie that has an active session.
Postman is not a browser so it doesn't "log in". The authentication in Postman is related to webservice calls. So imagine you have an online shop and you expose your API to a third party (let's say a sponsor or partner). For example you let another site (the partner/sponsor) add items for your common client from his site (instead of him having to logout of that site then login to your site, it's easier and your partnership makes both sites profitable, let's say for our example - so their site would be more like a sort of forwarder - when the user adds an item on the partner's site, they actually add it in the cart on your site).
In our example, they would call your API (for example, adding an item in the cart). The question is, how do they do that? How do you stop abuse from a malicious user? Simple: you add authentication. So what your (theoretical) shop's partner does is use some auth method (as you said, Basic Auth) to call the endpoint that results into adding an item into the cart for purchase.
But this auth is not what the client uses to log in to your partner or your site. It's an internal auth, like a sort of a "technical" user. And what you would do in Postman is simulate that call and the Postman login would be to allow it to call endpoints.
If, on the other hand, you have a separate login call that this is all it does, logging in, then yes, you can use Postman to login, BUT, keep in mind that the login auth info would not AND SHOULD NOT be the same as the API call login info. So you would still use an auth to allow the API call and a (hopefully different) auth for the actual login url as params.
In other words, Postman auth in any POST or GET call is just a way to tell the remote server they can trust you because you identify yourself. A login window like the Microsoft one is one for user accounts which is something totally different.
Related
Context
We are transitioning our Spring Boot application (with Angular frontend) from Spring's build in OAuth2 based security to Azure-AD. This is working well for clients we can update right away (mainly the B2B clients). However some (most B2C) clients can not easily be updated at the moment. In time this will happen, just not now. So I need a solution for the mean time.
Our idea
We proxy the request for the Azure tokens via the Spring Boot backend. From the client's point of view, it would look like the old solution. Username and password would be authenticated against the backend's database. Upon successful authentication, a certificate would be looked up for the user and this would be used to aquire an access and refresh token from Azure-AD B2C containg also a token for B2B.
That token would be wrapped into Spring's old OAuth2AccessToken and sent back to the client. The refresh request would be proxied in a similar way.
I have the refresh part working based on this: Web sign in with OpenID Connect in Azure Active Directory B2C -> Refresh Token
The problem
Using Microsoft's Graph API I can get an access token, but the part of the MsalToken extends AccessToken that is public (AuthenticationResult implements IAuthenticationResult) does not let me access the refresh token even if I request scope offline_access and if it is contained in the result.
Questions
Are there security concerns that make this idea a fundamentally bad idea? I'm aware that this requires trusting the backend, but that was the case so far. To me that does not seem to make it worse.
Is there a way to get an access- and refresh-token for a user be presenting the users certificate (or another none-interactive method - but we do want to use MFA as well for updated clients). I tried using Microsoft's Graph API, but a direct web-request is fine too.
In a .NET app I can add authentication and authorization using web.config and/or IIS. I can also use [Authorize (Roles = "RoleABC")] in a MVC app's controller or action. And even extend the AuthorizationAttribute
I'm looking into creating a React app for intranet use, and reading these tutorials (ReactJS and MS), but can't find authentication/authorization details.
Even though the app will be Single Page App, I still would like to authenticate and authorize users for certain options within the app, just like I can do in MVC app.
Is the only option to do that way is creating Blazor app instead?
For authentication and authorization, you should use auth tokens (like JWT). Your backend should create an auth token when a client logs in to the system and sends it to the client. Your server also should send the authenticated user information to the client (react app) so that you can render correct pages according to the user type. For example, you can render the admin page for an admin type of user, and the guest page for a guest type of user. You can save this user data as JSON in Redux. Hence you can access the user data from any component of your react. Also, in your backend, you must restrict the endpoints according to the auth token which is sent by the client. In the backend of my app, I follow the below steps:
Authentication check -> Authorization check -> controller (endpoint) -> result
React isn't opinionated on this, so it's up to you to design the implementation. A basic way to do this is:
Log in and obtain an authorized JWT token from the backend and include the account ID when you sign it
Store the JWT token in localStorage, store the account info in Redux
Conditionally limit routes based on account info (ie. admin group) on the front end
Have every auth-required API call include the JWT token in the x-auth-token header, then on the backend use middleware to check if it's still valid. You can then also decode the account ID in order to check its privileges so that you can limit API access
This may be helpful: https://medium.com/#faizanv/authentication-for-your-react-and-express-application-w-json-web-tokens-923515826e0#5f52
Not sure whether you still need this - I personally feel we should have something bridging the authZ gap between server and client to make it easy. So I spent a few days on a github project for this purpose, here it is: authzyin.
What I tried to do is to leverage policy based authorization from asp.net core - which I think it's very cool - and automatically bring the same definition to the client to use in React via hooks.
For authentication I am using msal.js against AAD - so authN is done on the client and jwt bearer token auth is used for all requests.
It has a client lib and a server lib which can be used together or separately. Of course it might still be lacking some features - please feel free to take it as a reference (contribution is also welcome).
I am trying to get the user who is logged in via. SAML Single Sign On.
I have already implemented SAML Single Sign On and it works.
The code I use for programmatic login is :
apps = gdata.apps.service.AppsService(email=username, domain=domain, password=password)
apps.ProgrammaticLogin()
logging.info("current user %s", users.get_current_user())
//Redirect to a Google mail page.
But users.get_current_user() returns None always even though correct username and password is provided. I have crosschecked it by redirecting the page to Google Mail page and it successfully redirects.
I have googled this issue for hours now nothing goes the right way.
Can anyone please guide me what I am doing wrong ?
There are three different things going on here, I just want to make sure are clear for my suggested answer to make sense:
Google App Engine users service: You, as the developer, delegate authentication and authorization responsibility to Google Accounts (or the selected OpenID provider). Google will act as the Identity Provider and you'll act as the Service Provider.
SAML single sign on: Google delegates to you the authentication and authorization responsibility, you'll act as the Identity Provider and Google will act as the Service Provider. You'll be using SAML SSO every time you try to login any Google service using you Google Apps account, that includes Google App Engine applications using the users service.
ClientLogin: It is one of the methods for authenticating to use a Google API by giving username and password. It's deprecated, it's hard to maintain and insecure since you are hard coding the credentials and the app could have access to everything. I'd recommend switching to OAuth instead. In the first two lines of code You are initializing the Google Apps provisioning API with gdata.apps.service.AppsService, if you are not going to retrieve or create users/groups/alias is useless to do that. If you are I'd also recommend switching to the Directory API part of the new AdminSDK
For your particular case I'd suggest checking if there is a current user logged in, if not redirect to the login URL using the GAE users service.
user = users.get_current_user()
if user:
logging.info("current user %s", user.email())
else:
return redirect(users.create_login_url(request.url))
In case you always require that the user is logged in you better set the handler as login: required
The user will be redirected to the SAML SSO page to log in to his Google Account in order to access the GAE app.
Having just implemented this, I have a pretty basic question about how authentication and oauth work together. I have a sample web app client (ckclient) that accesses a REST API (commitapi) for managing their commitments. This follows the model of having an app like LinkedIn displaying a user's Tweets (via Twitter) as described in: http://www.slideshare.net/coldfumonkeh/oauth-demystified-hopefully
In my simple app, a user goes to the web app client and asks to see their commitments. I am using Restlet and the user is redirected to a page where they can choose their OpenId provider and login. They are they redirected to a page where they can approve access to their commitment resources. Everything works fine.
But, the web app client doesn't know who the user is! All the authentication is done with the REST API, not with the web app client.
So my first question is... is this a bug or a feature?
My guess at the answer is that this is a "feature" - that is the way Oauth works - you don't WANT the web app client to know the userid/email address stored with the resource server (commitkeeper in my case, Twitter in the slideshare above).
If that is correct, then if I want the web app client to know who the user is, the web app client should provide user authentication. Since I am using Google's UserService on the server side, I also implemented UserService based authentication on the web app client. And now, if the user also does the web app client authentication, then the web app client has the identity of the user. So that is all good.
Combining these two also works - but I can't quite understand why.
On the web app, I login through Google's userService (technically with a GaeAuthenticator, that only uses Google accounts). Now the web app knows who I am and can display my email address.
From the web app, I ask the server for my commitments. The server responds by giving me the login page where I can pick my OpenId provider.
2a. If I pick Google, the UserService seems to know that I have already logged in through the web app and shows me my commitments.
2b. If I pick Yahoo (or something else), I have to authenticate with Yahoo and then I am shown the commitments for that Yahoo user.
This all seems fine to me - except for how does the UserService know that I already logged in? The webclient is at x.appspot.com and the server is at y.appspot.com. Is the answer as simple as the UserService is integrated across all of appspot.com?
In any case, thanks to anyone who can answer these two questions - or just confirm that I am on the right path.
(Note: I am using Google's UserService to create the login urls, my web app client and resource server are on appspot, using Federated Authentication, and all this is Java).
Well, the answer to the first part of the question is "feature" - getting resources from a ResourceServer via OAuth is not supposed to expose any user related information to the web app client.
I will pose a more specific question regarding how the UserService does its magic.
I'm plan on deploy a Java application to Google AppEngine and use federated login (still experimental according to Google). The application is pretty simple Java EE application which expose RESTful interface for simple CRUD operations.
I then want to be able to authenticate to this application using Windows Client Application written in C#.
I think the application should be able to open a window with a browser in ti which will present the login page of my web application and after successful authentication I should be able to get the login token or a cookie to use in the rest of my HTTP requests.
Is it possible to do such thing using federated login? I've found a post explain how to do it using google proprietary login.
Thank you,
Ido.
I've manage to make this work much easier then I thought it would be.
When I send HTTP request to my web service I get 302 Found response with response header name Location which point to the login page.
I use WebBrowser control, register to it Navigated even and navigate to the URL in the Location header.
When the Navigated even fire I use the code from this answer to get the cookies container.
I check each cookie until I find one with the name ACSID and store it.
For every web request to my service I add cookie name ACSID with the value saved at step 4.
This is not the most secure way of doing this. I will add check for the domain of the cookie but this looks good.