We're building a system to log in to a user's exchange account.
The biggest issue we're facing is determining the method in which to connect to a user's account - be it Exchange Web Services, Outlook Web Access, or WebDAV. How can we determine which is turned on, and which isn't?
Different protocols will provide different levels of access. Also different versions of Exchange Servers only support certain protocols. In order to be able to log into a broad range of email accounts you may end up having to support multiple protocols.
WebDAV is widely supported in Exchange 2000/2003. Support for it was reduced in Exchange 2007 and then dropped in Exchange 2010.
EWS is not supported in the earlier versions of Exchange but is well supported in Exchange 2007/2010 and Exchange365
IMAP is supported by all versions of Exchange but you would only have reduced functionality via this protocol
Related
I understand that PKCS#11 is std that defines cryptoki API and KMIP is a protocol that defines message format, but how they are connected or are they even interconnected?
How they both hold their individual significance in cryptography?
PKCS#11 can be considered a protocol of a kind too, it's used to communicate with the hardware devices (to be precise, with the driver modules of those devices). However, it's not suitable for network communications. KMIP is the protocol to communicate with remote key storages and similar services and use the remotely stored keys. This is similar to what PKCS#11 offers locally.
In theory, the protocols partially interlap and are to certain extent interchangeable - Oracle has the PKCS#11 driver/gateway, which talks to the remote KMIP server, and the opposite should also be possible. But, of course, each has its own strengths and weaknesses. Interestingly, both KMIP and PKCS#11 standards are developed by the same people in OASIS.
There's also a paragraph in Wikipedia that answers your question.
My understanding is that:
OStatus is a decentralized social networking protocol made up of several other protocols (Atom feeds, Activity Streams, PubSubHubbub, Salmon, and WebFinger)
GNU Social and Mastodon are two server software applications that implement OStatus
pump.io API is an interface to the pump.io server software (Activity Streams, OAuth, Web Host Metadata)
identi.ca is a pump.io instance (not accessible right now), GNU MediaGoblin is a server application that currently uses a pump-like API
ActivityPub is a proposed decentralized social networking protocol
GNU MediaGoblin is a server application that will likely implement ActivityPub
How do these protocols interoperate? Does ActivityPub completely replace OStatus, or only the Activity Streams component?
They are 3 different protocols that don't inter-operate. Though some software can communicate with 2 or more. Mastodon for example falls back to OStatus if ActivityPub does not work.
And so in that sense, to respond to your question, ActivityPub completely replaces OStatus.
OStatus is a decentralized social networking protocol which - as you say - is made up of several other protocols: Atom feeds, Activity Streams (version 1.0), PubSubHubbub, Salmon, and WebFinger.
It is still used by Friendica and GNU Social (formerly StatusNet).
It is no longer used by Mastodon. Support was removed in 2019 in favor of ActivityPub.
pump.io is an engine with an API that exposes Activity Streams (version 1.0). Pump.io was meant as a successor to StatusNet.
Identi.ca switched from StatusNet to pump.io in 2013.
Pump.io intends to deprecate their API and move to ActivityPub (see Developer docs).
Activity Streams is for the serialization of a stream of social activities using the JSON(-LD) format.
Version 1.0 was created by a working group that had Google, Facebook and Microsoft backing. It uses JSON as serialization format.
Version 2.0 was a sanitized version derived from 1.0 and uses JSON-LD as serialization format. It has become a W3C Recommendation that comes in two parts: Core and Vocabulary.
ActivityPub is a decentralized social networking protocol that is based upon Activity Streams 2.0 and it is the basis of the Fediverse. It is also a W3C Recommendation.
The ActivityPub specification is intentionally incomplete and flexible in a number of places. In order to create full-blown fediverse apps it should be combined with:
Webfinger (to find federated accounts)
HTTP- and/or JSON-LD Signatures (for server-2-server communication)
OAuth 2.0 (client credentials, authorization scopes).
For a long and ever-growing list of ActivityPub applications see the Feneas ActivityPub Watchlist.
So in summary OStatus, pump.io API and ActivityPub are three separate incompatible means to create federated social applications (that have nonetheless some common denominators). Of these ActivityPub offers the best way forward, and is the protocol you should choose from this list going forward.
PS. The best places to ask questions as an ActivityPub implementer are the SocialHub and Feneas forums. And see also the Guide for new ActivityPub implementers at SocialHub.
I want two users of my web application to agree to communicate with each other, and then my server would no longer be relied on for the communication. What are my options to have two computers communicate over the internet without relying on my server? How would I set this up--specifically, what API or protocol could I use?
I want to allow the users to run various secure computations, and I don't want my server to act as a trusted third party.
This previous question discusses the problem, but the answer is very vague. I know very little about doing web anything, and I'm having trouble finding where to look. Someone pointed me to the xmlhttprequest API, but I don't see how that is helpful.
It is possible with pretty new WebRTC technology. You should look at
data channels between clients. RTCDataChannel API provides secure (DTLS based) peer-to-peer communication. Not all browsers have support of the WebRTC and among them not all supports RTCDataChannel API. So beware browser compatibility problems.
Telegram is a cloud based chat service. All of their clients are open source. I was wondering if there's a way to host a 'private' telegram service on my own server.
If not, is there anything out there that can provide all or almost all features that telegram provides?
According to the official telegram FAQ the current answer is no:
Q: Can I run Telegram using my own server?
Our architecture does not support federation yet. Telegram is a unified cloud service, so creating forks where two users might end up on two different Telegram clouds is unacceptable. To enable you to run your own Telegram server while retaining both speed and security is a task in itself. At the moment, we are undecided on whether or not Telegram should go in this direction.
So as long as the server itself is not open-source the entire Telegram eco-system cannot be considered open-source, even though there is an open API and official open-source clients.
There seem to be some unofficial telegram servers, but it's not clear how compatible they are with existing clients.
Some possible telegram alternatives
Matrix is allegedly providing "an open network for secure, decentralized communication" and has both open-source clients (Element being the 'official' one) and an open-source server that can be self-hosted. BUT while it looks good on the surface, there are indications that companies behind it have undisclosed intimate links with governmental actors (similar to Signal).
XMPP/Jabber has been around for a longer time, is an open protocol with multiple server and client implementations, and might be the least tainted by third-party interests. XMPP was the underlying protocol behind the original Google Talk messenger before it was rebranded to Google Hangouts and switched to a proprietary protocol.
Teamspeak a collaborative platform for teams, intended originally for gamers, free client and server.
Mumble a voice oriented solution which allows self-hosted servers.
You could implement a full working Telegram-API, then have hosted clients on your server via this API.
Your users would login on your web, then you sign them in via the hosted clients on your servers.
You are basically performing a proxy service to these users , and you can even integrate other value added features for you users this way.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
If I have a separate system with its own concept of users and presence, what is the most appropriate architecture for creating a bridge to an XMPP server network? As far as I can tell there are three primary ways:
Act as a server. This creates one touchpoint, but I fear it has implications for compatibility, and potentially creates complexity in my system for emulating a server.
Act as a clients. This seems to imply that I need one connection per user in my system, which just isn't going to scale well.
I've heard of an XMPP gateway protocol, but it's unclear if this is any better than the client solution. I also can't tell if this is standard or not.
Any suggestions or tradeoffs would be appreciated. For example, would any of these solutions require running code inside the target XMPP server (not likely something I can do).
The XMPP gateway protocol you've heard of is most likely to do with transports. A transport is a server that connects to both a XMPP server and a non-XMPP server. By running a transport, I can use my Jabber client to talk to someone using, say, MSN Messenger.
A transport typically connects once to the remote network for each JID that it sees as online. That is, it's your option 2 in reverse. This is because there is no special relationship between the transport and the non-XMPP network; the transport is simply acting as a bunch of regular clients. For this to work, XMPP clients must first register with the transport, giving login credentials for the remote network, and allowing the transport to view their presence.
The only reason this has a chance of scaling better is that there can be many transports for the same remote network. For example, my Jabber server could run a transport to MSN, another Jabber server could run another one, and so on, each one providing connections for a different subset of XMPP users. While this spreads out the load on the Jabber side, and load balancing on your system may spread out the load as well, it still requires many connections between the two systems.
In your case, because (I assume) the non-XMPP side of things is cooperating, putting a XMPP server interface on the non-XMPP server is likely your best bet. That server interface is best suited for managing the mapping between XMPP JIDs and how that JID will appear on its own network, rather than forcing XMPP users to register and so on.
In case you haven't seen these, you might find them useful:
http://www.jabber.org/jabber-for-geeks/technology-overview
http://www.xmpp.org/protocols/
http://www.xmpp.org/extensions/
Hope that helps.
I too am working on a similar system.
I am going with the gateway/component route. I have looked at several options and settled with this one.
The gateway is basically a component with the specific purpose of bridging Jabber/XMPP with another network. You will have to build most of the things you take for granted when using XMPP as a client. Stuff like roster control.
There is very little help online on the actual design and building of a component. Like the above answer I found that the xmpp protocols/extensions to be of help. The main ones being:
Basic Client 2008
Basic Server 2008
Intermediate Client 2008
Intermediate Server 2008
Reading through these will show you what XEPs you will be expected to be able to handle. Ignore the stuff that will be handled by the server that your component will be attched to.
It's a shame that Djabberd has such poor documentation as their system of "everything is a module" gave the possibility of backend of the server could interface directly to the other network. I made no headway on this.
There are basically two types of server to server (s2s) connections. The first is either called a gateway or a transport, but they're the same thing. This is probably the kind you're looking for. I couldn't find specific documentation for the non-XMPP side, but how XMPP thinks about doing translations to legacy servers is at http://xmpp.org/extensions/xep-0100.html. The second kind really isn't explained in any additional XEPs -- it's regular XMPP s2s connections. Look for "Server-to-Server Communication" in RFC 3920 or RFC 3920bis for the latest draft update.
Since you have your own users and presence on your server, and it's not XMPP, the concepts aren't going to map completely to the XMPP model. This is where the work of the transport comes in. You have to do the translation from your model to the XMPP model. While this is some work, you do get to make all the decisions.
Which brings us right to one of the key design choices -- you need to really decide which things you are going to map to XMPP from your service and what you aren't. These feature and use case descriptions will drive the overall structure. For example, is this like a transport to talk to AOL or MSN chat services? Then you'll need a way to map their equivalent of rosters, presence, and keep session information along with logins and passwords from your local users to the remote server. This is because your transport will need to pretend to be those users and will need to login for them.
Or, maybe you're just an s2s bridge to someone else's XMPP based chess game, so you don't need a login on the remote server, and can just act similarly to an email server and pass the information back and forth. (With normal s2s connections the only session that would be stored would be SASL authentication used with the remote server, but at the user level s2s just maintains the connection, and not the login session.)
Other factors are scalability and modularity on your end. You nailed some of the scalability concerns. Take a look at putting in multiple transports to balance the load. For modularity, see where you want to make decisions about what to do with each packet or action. For example, how do you handle and keep track of subscription data? You can put it on your transport, but then that makes using multiple transports harder. Or if you make that decision closer to your core server you can have simpler transports and use some common code if you need to talk to services other than XMPP. The trade off is a more complex core server with more vulnerability potential.
What architecture you should use depends on the non-XMPP system.
Do you operate the non-XMPP system? If yes, you should find a way to add an XMPP-S2S interface to that system, in other words, make it act as an XMPP server. AOL is using this approach for AIM. Unfortunately, they have restricted their gateway to GoogleTalk.
You don't operate the non-XMPP system but it has a federation interface that you can use - i. e. your gateway can talk to the other system as a server and has a namespace of its own. In this case, you can build a gateway that acts as a federated server on both sides. For I don't know of any example of a gateway that uses this approach but you could use it if you want to build a public XMPP-to-SIP bridge.
If the non-XMPP system doesn't give you a federation interface, then you have no other option but acting as a bunch of clients. In the XMPP world, this is called a "transport". The differences between a transport and a normal server are basically:
the JIDs of the transport are mapped from another system (e.g. john.doe\40example.net#msngateway.example.org - really ugly!)
XMPP users who want to use the transport need to create an account on the non-XMPP system and give the login credentials of that account to the transport service. The XMPP protocol even has a protocol extension that allows XMPP users to do transport registrations in-band.
One other approach is to work with your XMPP server vendor. Most have internal APIs that make injecting presence possible from third party applications. For example, Jabber XCP provides an API for this that's really easy to use.
(Disclosure: I work for Jabber, Inc, the company behind Jabber XCP)