I have been asked to integrate Facebook Chat to my application using JavaScript only. I cannot use X Facebook platform authentication as it needs a domain URL. So my option is to set up an XMPP chat client using strophe.js via a digest MD5 SASL mechanism.
Regarding BOSH connect manager, http://bosh.metajack.im:5280/xmpp-httpbind. Is this enough or should I configure it in my server? I am using the Tomcat server.
Facebook does not do S2S federation, only C2S, so you will have to use that as your XMPP server (or implement something like XEP-0100 at your server). Facebook does not currently support BOSH, AFAIK.
from http://developers.facebook.com/docs/chat/
The DIGEST-MD5 SASL mechanism is available to support traditional XMPP
or multi-protocol IM clients that are
not customized for (or even aware of)
Facebook. This mechanism requires
prompting the user for his or her
password; therefore, it should only be
used when necessary. In particular, it
MUST NOT be used for any client that:
•Proxies the XMPP connection (the
connection must be directly from the
user's computer to Facebook).
•Reports
messages or any other information
about user activity to a third party
(including the client developer).
•Integrates with Facebook, or has a
Facebook Application ID. If your
application does any of the above, you
must use Facebook Platform
authentication instead.
So, you can't use DIGEST-MD5 with a bosh server but you must use X-FACEBOOK-PLATFORM
Related
Currently, I have a social media project that already has the existing users, I want to enable the chat function. I had config Ejabberd with JWT and Mysql. I tested and I realized that I don't have to register the users in order to chat, I just need to make sure my token has "JID". Is it a good approach? Or do you have any other suggestions?
You don't need to register the users to ejabberd server explicitly while using external authentication mechanism.
However, chances are that you might not be able to see the list of registered users on the admin panel when not using the default authentication mechanism.
My company distributes an application with a background service component that sends and receives mail from a single email account using SMTP/POP3.
The app uses basic authentication, but we need to implement OAuth 2.0 now due to Microsoft's planned rollback of basic auth for POP3 (and likely SMTP in the future). We have been investigating the account setup and API permissions necessary to achieve this in Azure AD.
Our current understanding is that it is possible to implement the 2-legged client credentials flow by getting an access token and then sending requests to the Graph API (eg. https://graph.microsoft.com/Mail.ReadWrite). However, our application is built to send and receive with the legacy SMTP/POP3 protocols and changing the mail features to send HTTP requests to the Microsoft API endpoints requires a partial redesign.
It appears that only 3-legged flows are supported for the legacy SMTP and POP protocols. These permissions are only available as "delegated permissions" on the Graph API. There are no equivalent "application permissions" that would allow us to use these protocols from our background service without a user present to do the initial authentication.
Integrating a browser redirect into the app for the initial authentication also requires a significant update to the application. The app is 14 years old and the original programmer is no longer at the company. Due to that fact as well as limited resources, we're hoping for a solution that doesn't involve implementing browser integration or major changes to the sending and receiving functions.
Is it possible to implement a 2-legged OAuth flow to authenticate an account for sending and receiving over SMTP/POP3?
Might any of our assumptions be incorrect?
No. It's impossible.
OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported.
Currently the supported flows are:
OAuth2 authorization code flow
OAuth2 Device authorization grant flow
See details here.
If you have this requirement, you can post your idea on Microsoft Graph user voice.
I know that both the federation protocols can be used to manage user identities.
Basically for Gmail based login, I want to know the benefits of using OpenID Connect over SAML.
OpenID connect is simpler JSON/REST based with compared to SAML. Apart from this is there any benefit of using OpenID Connect for Gmail based authentication?
It depends on what you call "GMail based login".
1- if you mean let my users read their mails on GMail using their credentials maintained in my internal organization, OIDC and SAML will do the same. This is simply not the same protocol. So, depending on your internal directory (Active Directory, NetIQ eDirectory, openldap, /etc/passwd, etc.), it may be easier to use one of these protocols.
2- but if you mean connect to GMail with my application, on behalf of my users, only OIDC will let you do that, because of the underlying OAuth2.0 mechanism.
OIDC means authentication and authorization, SAML only means authentication.
Historically, SAML and WS-Fed were used for enterprise connections and are browser based.
OIDC is for mobile and can be used via ADAL for native devices i.e. non-browser based e.g. dektop applications.
I have an HTTPS WebService that need to be accessed from a Mobile (iPhone) application. both are developed by our-side.
We need to secure the Mobile access to this Service. So we used a username/password credentials.
We are aware of OAuth, but we need a more simple authentication scheme.
What We think of is the following:
The Mobile App shows a Login-form to the User/Resource Owner.
The Resource Owner enter The login credentials on behave of the Mobile App.
The Mobile app connect to the Server at special WS Method (e.g. "ValidateLogin") that takes username/password -probably hashed- as input and returns the HTTP Session Id.
The Mobile app persists this HTTP Session Id -which is a unique key from server side, and may be secure?- to communicate with the Server for subsequent requests (Invoking business methods).
If the Client doesn't communicate with the Server for say 30 Min, the Server will send 403/Session_time_out (The Mobile may remove the persisted HTTP Session Id to indicate to himself that he no longer has access to the Server resources - and It may opt to do so in case if it needs to end the communication with the Server)
In this case, the Mobile will need to use the Resource Owner again to obtain a new session id from the Server and gain access to the Server resources.
The Questions are:
Does the above steps are good enough to depend on?
What do you think from security perspective?
Do you have any other thoughts/opinions?
EDIT: It is a HTTPS WebService
The question is very open in nature, and I believe that it is difficult to answer those general questions with your specific needs in mind.
To answer some concrete questions:
How to secure your app against unauthorized clients?
Look at SSL and Client side certificates.
How to manage user credentials securely?
Look at using the Keychain API in iOS.
I'm starting to create an iPhone/Android app that will need to use Plone users (i.e. register on the website and then enjoy the app on your mobile).
What's the best approach on doing this? I've seen some apps using OAuth or other techniques, which ones currently supports Plone4 (4.0.3 exactly).
I have the users on a LDAP server (OpenLDAP) but even that I still have to log them on Plone to be able to send and retrieve data from there to the mobile phone.
You have 3 options, and what you choose is dependent on what your skills are and how much time you are willing to invest:
Basic auth
Have your user enter a username and password into the app, and just use HTTP BasicAuth headers to access the site. Plone supports Basic auth authentication out of the box.
This is not the most secure method; passwords are basically sent base64-encoded, so you may want to use HTTPS to communicate with the server. A good idea in any case for authentication anyway.
Cookie authentication
Send a POST request with __ac_name and __ac_password items to '/login_form' on your Plone site, and capture the Set-Cookie header on the response, containing the __ac cookie. That's a tk-auth authentication token you can use on any subsequent request. This is a secure cookie, but any attacker sniffing the HTTP communication stream could re-use this, so again HTTPS is the secure way to communicate.
OAuth
Plone does not (yet) support OAuth out of the box, but integrating with python-oauth should be trivial. This would most likely require a PluggableAuthSystem (PAS) plugin to be written.