What set of Windows API calls will allow downloading a web resource (specifically an XML document) when the site is protected using Digest authentication without having to enter a username and password?
I can use MSXML's “open” function on the IXMLHTTPRequest interface, but it requires a username and password to be supplied even though I'm logged on to the Windows domain server.
Internet Explorer can accomplish this task without requiring me to enter this information.
I'm not familiar with this particular API. But it looks like there is a function to set a request header called setRequestHeader so have you tried adding the following line directly to the request header?
Authorization: Basic %s\r\n
Note: %s is name:password in base64 encoding.
Related
I'm attempting to use Postman to "Get User Access Token" with Microsoft Graph API; however, my org recently enabled multi-factor auth and this call is now failing, stating:
"error": "invalid_grant",
"error_description": "AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access...
The Microsoft documentation for MS Graph API using Postman is very well written, but it is missing clear instructions how to pass in this second factor to the request.
The error points to https://login.microsoftonline.com/error?code=50076, but this just gives the same info.
I have the MS authenticator app which gives me this key/second factor; however, I don't know how to add this into the body/headers. I'm trying to find the specific key name for passing in the additional security token (I've tried things like 'token,' 'pcToken,' 'key,' etc.)
.
I was in the same predicament so here is what I did to solve it:
Firstly, I got the information from:
https://github.com/microsoftgraph/microsoftgraph-postman-collections/issues/4
You will need to use the OAuth 2.0 authorisation in Postman. Using the same GET request, go to Authorization -> Change the type to 'OAuth 2.0' then click 'Get New Access Token'.
From there, you can input your own details:
(replace [TenantID] with your own)
Callback URL: The redirect URL you stated in your app authentication.
Auth URL:
https://login.microsoftonline.com/[TenantID]/oauth2/v2.0/authorize
Access Token URL: https://login.microsoftonline.com/[TenantID]/oauth2/v2.0/token
Client ID: You're application's ID.
Client Secret: You're Applications secret that you set under the 'Certificates & secrets' section.
Screenshot
Username Password Authentication is not supported for MFA because MFA requires interaction. But there is no interaction if you need to use Username Password Authentication to sign in.
See Username Password Authentication：
users who need to do MFA won't be able to sign-in (as there is no
interaction)
The answers above do not describe anything related to MFA by-passing via code.
MFA auth you need to use broker authentication where MS Authenticator app behaves as a broker.
If you integrate the proper libraries (ADAL, MSAL) your code will be able to interact with broker properly.
On Android and iOS, brokers enable:
Single Sign On (SSO). Your users won't need to sign-in to each
application
Device identification (by accessing the device
certificate which was created on the device when it was workplace
joined). We use Intune-managed devices for this purpose.
Application identification verification (is it really outlook which
calls me?). The way it works is when an application calls the broker,
it passes its redirect url, and the broker verifies it:
On iOS, the redirect URL is, for instance, ms-word://com.msft.com, the broker
parses and gets the appId (after the //) and verifies it's the same
as the appId of the calling app, which it knows (by the OS).
On Android the redirect URLs have the following form msauth://com.msft.word/.
To enable one of these features, the application developers need to set the UseBroker Boolean to true in the platform parameters. They also need to implement a delegate to react to the broker calling back the application as described in Platform parameters properties specific to brokers on Android and iOS.
Please refer to the MS docs for broker auth examples:
https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/leveraging-brokers-on-Android-and-iOS
https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-use-brokers-with-xamarin-apps
https://learn.microsoft.com/en-us/azure/active-directory/develop/brokered-auth
I am trying to connect to my app on kinvey. From a browser, I can simply use:
https://baas.kinvey.com/appdata/<app_key>?app_secret=<secret>
I do get prompted to enter app_key and app_secret as uid and password but at least I get:
{
version: "3.8.13",
kinvey: "hello <my app name>",
appName: "<My app name>",
environmentName: "Development"
}
but, from python, I cannot. The closest I got was with:
requests.get('https://baas.kinvey.com/', headers={'app_key': app_key, 'app_secret': secret})
That takes me to a generic kinvey 'hello' but not to my app.
I also tried with
requests.get('https://baas.kinvey.com/' + app_key, headers={'app_key': app_key, 'app_secret': secret})
If i try to add the app_key + '?app_secret=' + secret to the url I get an error on malformed header/missing credentials.
Thoughts?
The correct way to add credentials to a Kinvey mbaas request is by setting a Basic Auth header, as explained here. Using the headers that you describe is not supported.
The steps here are that you use a base64-encoded appkey/appsecret to build a Basic Auth header in order to get to the "login" endpoints, after which you'll get a Kinvey token for the session authentication corresponding to the active user. There is no such thing as anonymous access to your app, apart from getting to the login endpoint.
Basically, this is not trivial. This is why using the REST API directly is not recommended, and using a specific SDK for your platform is. There's SDK's for many platforms including java/android, javascript, C#/xamarin, xcode/swift, etc. In those SDK's, you simply call functions like "Kinvey.login" or "Kinvey.appdata.get" and all auth and all offline, caching, etc. is taken care for you.
I'm very novice when it comes to web applications and ASP.
Recently, I've been experimenting with the Microsoft Sync Toolkit to synchronize databases over a OData web service.
The obvious question here is: Once the service is set up and published - so it is open for anyone knowing the URL - how to prevent unauthorized users from accessing this service.
Please note: Basic authentication of forms authentication - as far my little web development knowledge reaches - doesn't seem to be appropriate for this task, as it's not a web page that the client is trying to reach - where the page can display / or re-direct a logon request - it's a service that we are accessing here.
To make things more difficult, for the client-side syncing I'm using a 3rd party library/sync-provider that only accepts a URL for the service. So, there's no way (I think) I can experiment with incorporating login credentials inside a request header etc.
I assume the best bet would be embedding the login credentials inside the URL and use that for the 3rd party library.
Can somebody please direct me how to to set up such thing on the server? I would prefer to have somehow somewhere in the server-side code a place where I can check for the credentials and based upon it to proceed or abort (return 401) the service request.
I could not find any place where to hook such code into the sync service. Although somebody in MSDN suggested to handle the _OnBeginSyncRequest event, there is no way to access the web-request header from within that method.
Is there by-any-chance a global object accessible from everywhere from which I can access the request header? Could anyone please help with this?
And last, I would prefer a plain User / Password string pair. It should not necessarily (or rather not) have anything to do with windows or directory accounts. I would prefer in my code to simple check against plain strings, such if(userStr == "Authenticated user" && passwordStr == "Correct Password").
if you are using SOAP web service, you can use WS-Security usernametoken which adds your user name and password to the request header, otherwise you can add username and password as parameters in your webservice and then simply validate it on the server side. i.e.
instead of
bool SyncData(datatable)
it becomes
bool SyncData(datatable, username, password)
note for web service you will authenticate per call, if you want to do it per session, you need first login with username password, retrieves a token than on each subsequent call your service with the token.
You would also use SSL to secure the channel so username and password aren't transmitted as plain text.
I have server with some resources; until now all these resources were requested through a browser by a human user, and the authentication was made with an username/password method, that generates a cookie with a token (to have the session open for some time).
Right now the system requires that other servers make GET requests to this resource server but they have to authenticate to get them. We have been using a list of authorized IPs but having two authentication methods makes the code more complex.
My questions are:
Is there any standard method or pattern to authenticate human users and servers using the same code?
If there is not, are the methods I'm using now the right ones or is there a better / more standard way to accomplish what I need?
Thanks in advance for any suggestion.
I have used a combination of basic authentication and cookies in my web services before. In basic authentication you pass the user name/password encoded in the HTTP header where it looks something like this.
Authorization: Basic QWxhZGluOnNlc2FtIG9wZW4=
The string after the word "Basic" is the encoded user name and password that is separated by a colon. The REST API can grab this information from the HTTP header and perform authentication and authorization. If authentication fails I return an HTTP Unauthorized error and if they are authenticated but are not authorized I return an HTTP Forbidden error to distinguish between failure to authentication versus authorization. If it is a web client and the person is authenticated then I pass the following in the HTTP header with a request.
Authorization: Cookie
This tells the web service to get the cookie from the HTTP request and use it for authorization instead of doing the authentication process over again.
This will allow clients that are not web browsers to use the same techniques. The client can always use basic authentication for every request, or they can use basic authentication on the initial request and maintain cookies thereafter. This technique also works well for Single Page Applications (SPAs) where you do not have a separate login page.
Note: Encoding the user name and password is not good enough security; you still want to use HTTPS/SSL to secure the communications channel.
I have created a simple server accepting tcp and http requests and parsing them in C++. Now I want to create an openID login system which would support Google open ID. I use boost and Curl in my server. Currently I have no ssh in my server except curl can make ssh requests.
So what do I have:
html get/posts requests parsing into maps of map<string, string>
curl with ssh support
file returning server functionality (with modified response arguments)
What else shall I implement to support the possibility of google OpenID login? (I need only some basic unique identifier from user - not his\her name or any other details)
What shall be my steps in order to get unique user ID in server that recieved request with something like openIdLogin :https://www.google.com/accounts/o8/id in it?
I need some simple, readable instructions like once provided by google for reCAPTCHA Verifying the User's Answer Without Plugins - where shall user be redirected, what shall be in Request, Response etc. (not pure Specs)
From the open ID wiki
http://enthusiasm.cozy.org/archives/2005/05/openid-part-iii-pingpong
or from Google's own doc
http://code.google.com/apis/accounts/docs/OpenID.html#Interaction
What it sounds like you are looking for is Google's Federated Login. What it basically amounts to is sending some url requests to Google's servers and providing a callback url where you want the user to return to after they login on Google's servers.
Towards the bottom of the page there are some sample requests and responses that should help you get started.