Using privacy list manager to handle blocked users i can be able to store and retrieve blocked users. but not be able to block the communication between the blocked users. will openfire support XEP-0016 fully? if it supports then why am getting message from blocked users, Any idea why?
Privacy Lists are supported in Openfire but there is no specific mention of XEP-0016.
Privacy lists are stored in "ofPrivacyList" table in database. If you are blocking a user, then verify from this table that if it's entry exists there or not.
Same is answered here: Does openfire support User / contact blocking?
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
We use XERO to authenticate and sign in to our app on firebase, however, we dont want a user to connect with multiple organisations, we just want a user to sign in and choose a single organisation.
If we remove all tenant connections from our app once a user have finished signing in, this will solve our problem, and we already do this upon logout for the same reason.
I just wanted to find out, is there any implications of doing this ? Will our logged in user still be able to make api calls and get new access tokens ?
I could not find any info of this in the XERO docs.
Thanks
The list of connected tenants represents the orgs the user has authorized your app to interact with their Xero data on their behalf. Deleting the connections by making a DELETE call to the connections endpoint with a specified connection ID will effectively un-authorize your app to interact with that orgs Xero data until the user reauthorizes your app to do so.
So, the shorter answer is - no, you won't be able to make api calls after disconnecting.
What I think you are after is limiting the XeroAPI access_token to only be able to write to a single org at a time. This can be achieved through your UX by simply deleting all connections if they try to go through your authorize flow a second time.
That way you are limiting their API connection to a single org, and if they want to change the org they are connecting to they can use your UI to disconnect/reconnect to another one.
XeroAPI Documentation
https://developer.xero.com/documentation/oauth2/auth-flow
Removing connections
If you would like to remove an individual tenant connection from your app (e.g. a user wants to disconnect one of their orgs) you can make a DELETE request on the Connections endpoint:
DELETE https://api.xero.com/connections/{connectionId}
I am developing a WCF service which can be consumed by mobile applications to authenticate users against the corporate extranet ActiveDirectory. I am using a customized version of this implementation from Microsoft. I need to implement the account lock out logic so that after n retries the account in the ActiveDirectory should get locked-out.
I tried with state-full WCF service to keep track of the failed log-ins. But the client can start over the next session and continue with the attack.
I know that the ActiveDirectory policy can be set to enforce this, but just querying the AD -like the Microsoft solution does to authenticate the user - does not lock out the user.
So, I am looking forward for a solution which will work like when log-in to Windows with incorrect password for n times the account will get locked-out as per the policy set in the AD.
I have not seen your code. So I'm guessing you have similar solution that is implemented in this example, have a look at this link
In above example, please have look at line
DirectoryEntry entry = new DirectoryEntry(_path, domainAndUsername, pwd);
this entry object would be used for authentication when you make a search call on active directory.
If you are using user/password that you want to authenticate then you need not to worry about locking it by your code. Active directory policy would be enough.
But after reading your comment I guess you have one specific user that you use to search mobile application users to check if they exist in your active directory or not. If this is the case effectively you are never authenticating against mobile users so those users never going to be blocked automatically.
I would be interested to know your answer.
There are basically two ways of doing this:
You continue the directory search method you are using, but track the number of logins for each user in a custom database, and check this database before doing the directory search.
Use the Windows login instead, and rely on AD to lockout the user. For a description of how to do this check: Active Directory (LDAP) - Check account locked out / Password expired
Edit
After seeing marc_s's comment, I am unsure if doing the directory search will lockout or not. It would actually be a serious security hole if you could try an infinate number of times. But you would need an account that is allowed to query AD before you could use it.
The code you linked to had this line
object obj = entry.NativeObject
Which was to force authentication. Have you included this line?
Background research:
User Signup in Couchapp/CouchDB through jquery.couch.js or Otherwise
http://blog.couchbase.com/what%E2%80%99s-new-couchdb-10-%E2%80%94-part-4-security%E2%80%99n-stuff-users-authentication-authorisation-and-permissions
https://issues.apache.org/jira/browse/COUCHDB-1175 - specifically "Ari Najarian" 's posts
Question:
To paraphrase the SO question I posted above:
"Essentially I want to have a signup form for registering an account in couchdb for a couchapp. This would entail creation of a new user in the couchdb _users database, and the creation of a new database, with the new user assigned the role of database admin. All that requires server admin credentials."
The answer to the previous question involved using an external separate server that was logged in to couchdb as admin to monitor couchdb and modify couchdb as desired in response to certain data events coming from a client.
My question is - is that the only way? Doesn't that defeat the whole purpose of couchdb's 2-tier web stack? Is there some way to modify a couchdb database from within a validation function which checks for "type == user" document while "internally"/separately logged in as an admin maybe?
I apologize if there is some straightforward way to do this and I just didn't find the right documentation.
Extra Problem Clarification:
There is the couchdb instance sitting at an internet address.
This couch database serves to a random client an html page and embedded javascript script that contains a signup/login form.
The client enters signup info (name, password) and submits
The JS script uses the XMLHttpRequest object to open a connection to the couchdb instance and sends...PROBLEM!
Problem #1 - If the credentials are stored in the code (to be sent as verification for new user database), then anyone could "view html source" and take over the database.
-OR-
Problem #2 - If credentials are not supplied and the request is sent anonymously, then a new user will be created in the _users database and a success reply message will be sent. But no new database was created for the user (and can't be without admin credentials) which the user can interact with for application-specific purposes (e.g. add/delete data). And - from the above couchbase blog link - if you have secured your database with roles/names against anonymous readers and validation functions to prevent anonymous writes, then an anonymous-made user account (e.g. a client who wants to register database space to use the app) can not do anything because an anonymous user cannot, for obvious security reasons, specify whatever roles they wish to have. Which means that the only way to have -functional- users is to create user accounts + associated databases as admin beforehand and then hand out these user credentials - so like a private invite system, yes?
To reiterate, is there any way, using ONLY couchdb and some combination of couchdb's authentication handlers, design document functions, client-side ajax, etc. for a connecting client to register and get a personal database (and ONLY that database obviously) they have access to and can interact with?
This isn't a PURE couch solution, but it's couch + node, and solves your problem:
Hi I haven't been around in awhile and didn't realize this was edited / link removed (plus policy of links not being answers! sorry...). I have been using couchdb on a project very similar to what you are trying to do, and unfortunately there is no way to do what you want to accomplish without tacking on another service to handle the admin-level access and creation of user database. Syncpoint-API can be used to facilitate this, but it is actually a nodejs service handling the signup/login and dedicated database setup.
So far though, Syncpoint has proven to not be 100% reliable and it does appear to be an abandoned project, due to CouchBase sucking all the r+d resources away from CouchDB dev.
I'm now moving to nodejs + socket.io as a transport layer, using node to handshake and assign a DB, and then further watching the couch _changes api on the server (via yet another node process) to then forward _changes through socket.io to the client. Also I have some "pure" couchapps running that serve public data mixed in with the private data.
My conclusion? CouchDB is a great product and has some great features, but for the more complex login/authorization schemes and other general application needs required in real-world dev, it's just not ready yet.
I have the following scenario.
At my company we use Oracle 11g. The authentication on the frontend is using database users. So, every user of the frontend has a his own user account in the database system.
This implies that they have the ability to connect directly to the database, if they know the IP address, port, etc,. Of course, this is not considered a security concern because our strict managment of roles and privileges. This also implies that when a new user is added our DBA have to create the user and assing the proper roles and privileges.
Until now, our frontend is accesed only by our internal users. However, We are planning to add the capability for our external users can login in our frontend.
Our estimation is about 750,000 external users with annual increments of 50,000. This users are supposed to access our system three or four times per year.
The question we have is how to grant access to this users.
By using our already implemented authentication system. Every user has his own database user account.
Generating an authentication system for external users only. Like most of the CMS's in the market, with tables as an ACL (Access Control List) for users, passwords and roles for our 750,000 external users.
My main concern is to have +750,000 database user accounts that will be unused most of the time and eventually could make a mess with our internal users.
Someone have a similiar experience with this amount of users and how did you deal with it?
Best regards.
Off the top of my head..
Make sure that whatever outward facing boxes are few in number.
For the boxes that can connect to the database - make them purely
authentication or get/put for the data. don't run the web server on the databases or on the same LAN segment.
If possible encrypt communications from the client to the database so that if any of your intermediate hops get rooted they'll only see junk.
Use a firewall to ensure that only the bare minimum can get through.
For validating authentication, don't let their 'real' password get off the web server. Keep it hashed, San Diego!