Original jamesiarmes/php-ews offers authentication only by username / password. Fork by Garethp has some OAuth function but it requires Office365 and registering application in Azure. Is there any possibility to connect to Outlook by web browser just relying on user logged to Windows System? I know how to read which user is logged using kerberos, but don't know if it's right tool to make it.
There's no way with either of those tools. I looked in to trying to use Network Authentication as method of Auth, since my fork uses NTLM any way, but I couldn't find any resources on passing the NTLM Authentication over SOAP calls. That being said, if you can find some examples, I'd be happy to build it in as a method of authentication for you
In the EWS service object, you can select the flag to use default credentials, meaning whatever user context the code is running under. Would that help?
Related
I am trying to connect and query our foundry ontology from different Microsoft tools in our own network. I was able to do so using a token as described in the documentation. That works great and it is easy to configure. The problem is that it is associated to only one account and the token expires often.
Reading the documentation I saw the option for OAuth. What is not very clear in the documentation is whether we have to register an application for ODBC and how to do it. When I have had to register applications in the past in cloud environments, the application normally has a returned address that the cloud app hits to authenticate. However, in this case, I don't see how that would help for ODBC from desktop applications like Excel or Access.
Any suggestion or reading would be appreciated
To use the OAuth flow with the ODBC driver on Windows you can register a third-party application in Foundry (see docs). You can use a public or confidential client, and the redirect URL should be set to http://127.0.0.1/foundrydriver/oauthredirect.
I've built an authenticated .net core (5.0) web application using Identity (2.2) and set up two factor authentication using a smartphone authenticator app. This is all working fine. I'm now trying to configure the application to enforce the two-factor authentication so that in order to reach any controller / action (apart from those needed for the authentication process), a user MUST be two-factor authenticated, by which I mean they must have enabled 2FA, set up the smartphone authenticator app and then gone through the two-factor authentication process. I'm sure there must be an easy way to do this, but I'm unable to find any posts anywhere on how to do it. Can anyone help? Thanks in advance.
I'd like to implement kind of SSO for openshift, what I mean: from my webapp a user can open openshift console in a new window without giving his credentials. I've configured Basic Authentication Remote and it's working, can open new window and post username/password but it's looks that openshift is protected with crsf token. Thus not sure if it's possible at all. It seems that developing custom identity provider is not supported either. Any idea ?
PS I'm aware of Request Header Identity Provider but that solution requires my webapp to provide idp functionality (not even sure if it's feasible), also apache (we use nginx), a lot of issues for dev to install it all on a single computer due to port conflicts, valid ssl etc etc
Best option will be to use oauth proxy. See if this helps in your case.
https://github.com/openshift/oauth-proxy
Finally I've implemented SSO using js postMessage to send user/token data and Basic Authentication Remote.
I'm new to Federation Services and I'm trying to understand how ADFS works as a whole and I've started to get down into the details. I followed along with creating an app using OIDC to authenticate a user, however, within the tutorial, they specified using a "Server Application" when setting up an Application Group. This ended up not working for me so I tried setting up a "Native Application" application group for kicks and was able to successfully login.
The thing that threw me off is, I ended up hosting ADFS on a server outside of the domain in which I had my application running, so I'm confused as to how that is "native" in terms of ADFS.
I went looking for this answer within microsoft's documentation but I didn't find the information very clear.
Native Application:
"Sometimes called a public client, this is intended to be a client app that runs on a pc or device and with which the user interacts."
Server Application:
"A web application that runs on a server and is generally accessible to users via a browser. Because it is capable of maintaining its own client 'secret' or credential, it is sometimes called a confidential client."
This may seem simple to some, but I'm trying to really get a grip on what would be used when. To me it sounds like a native application is used when you're running the application natively on a pc in which the user is also using the same pc, and the server application is run remotely in which the user would not be using the same machine. Is it really that simple or am I misunderstanding?
A native application (in Microsoft speak) is something that is not browser based e.g. mobile. The code runs client side. It may use JavaScript in which case the secret key is publicly accessible. (The secret key is one of the OAuth parameters). You use ADAL / MSAL to access it.
A server application runs server side e.g a web API. The secret key is not publicly accessible. You use OWIN to access it.
These terms have no relevance to where ADFS is actually installed. Native applications typically are not domain joined.
Our setup is like this: we use a coldfusion 10 server, and files are on a local intranet. Users use a domain login to access any files over https. I'm interested in using html5 websockets, but the first attempt gave me an error because no credentials were supplied. Is there a way around this? If not, is there a recommended technology for this scenario?
The user does log in on the client side. If it's possible, what I'd really like to do here is pass those credentials when making the connection to the server.
you should be able to supply the authentication header to your web socket server before the elevation to web socket read that and send it back in the headers for the elevation (first frame) then when the browser connects it should have the authentication it needs.
if your using a custom authentication E.G in page not authentication header you can also do this by passing any custom header to your server.
Or mandate that the first thing your web client sends is the authentication details this could be something like {username_hash}.{password_hash} if they don't close the socket to them.
Do not do this.
You're now responsible for sending and encrypting the authentication credentials yourself, bypassing something that already works and is tested.
Anyone can snoop on an unencrypted websocket port. Use HTTPs for an intranet, use stable solutions, don't reinvent this wheel because it tickles your fancy.
In a couple of years some colleague will have to maintain this and will have to figure out how your homebrew version works versus something that's solid like plain browser authentication.
My advice: Leave this to the browser and to well-tested coldfusion libraries.