I want to use pubnub access manager for keys used on web and other set of keys without access manager on mobile devices. Can they both have access to same channels data.
PubNub Access Manager
No. A key set (set of pub/sub/secret keys) is a namespace for channels. So channel abc of key set #1 is not the same channel as abc from key set #2.
But with PubNub Access Manager, you would grant one set of permissions for channel abc to auth-key user1-auth and another set of permissions to auth-key user2-auth. So you do not need two sets of keys.
Related
Is it possible to get DocuSign Signing groups from account ABC and create same Signing GROUP in account XYZ? We know that we can create signing groups using DocuSign API. Our main concern is that We want to create/import Signing Groups with same SigningGroupID.
As we are saving Signing group ID in our application processes and we want to use same Signing group IDs in some other user account.
Could you please confirm us if this is possible and will not cause any issues?
Is there any other option available for us?
Signing groups are an account object. That means they are part of a specific account. They use a numeric identifier (up to 1,000,000) that is unique inside the account and is generated randomly when you use the API to create a new one.
There's no way to set the group ID directly.
Your best solution is to have a mapping table in your database that maps your groups to your accounts. Another solution is to first make an API call to obtain (list) all the groups and find the one you want and its ID. That solution is less recommended as it requires an extra API call each time.
I have one Salesforce profile and one permission set in Salesforce. As per the requirement, there are two user personas in our Salesforce application.
Persona 1 -> SF Profile
Persona 2 -> SF Profile + Permission Set
To achieve the above configuration using Azure AD auto-provision, we have created two security groups and added relevant business users into those two groups. Currently, we struggling to determine the best approach on how to assign the Salesforce permission sets to the users in the "Persona 2" user group.
You already have Single Sign-On configured in SF, right? At the bottom of the page there's place for just-in-time (JIT) login handler class.
You'd have to write that class but there are some online examples for ... implements Auth.SamlJitHandler. Once you have the class skeleton ready - use System.debug(JSON.serializePretty(attributes)); or something similar to see what Azure Active Directory sends. Last time I used this AAD couldn't send groups info but it could send role(s). So we determined unique sets of users and if role is X - check if the user has permission set X assigned and if not - assign it. We then expanded it to other SF features (groups, queues, user role, profile...). PermissionSetAssignment is the table you need.
If you don't want to write code for this there's always Identity Connect but that's paid and on-premise agent program (I think). No idea if it can work with AAD. But you'll get simple interface for the mapping.
We set up Hyperledger Fabric and added two channels (for two different applications). We also registered two users in our Organization (one for each application). We should restrict access to each channel so only the corresponding user can read and write based on affiliation or OU of the user.
We checked Hyperledger Fabric documentation on channel policies and did not find any indication on how to use OU or affiliation (i.e. conditions that go beyond "must be member of orgX").
From what I've read so far, I got the impression that restrictions within the organization can only be enforced in chaincode, but not by using policies (this is also indicated in this question).
Is this really the way to go? Is there no possibility to restrict access to either a OU or an attribute like affiliation by just using the channel policy?
You can define an MSP that is defined with the OU you have in mind, and then the user will have to belong to that MSP and use a certificate with that OU when it sends transactions.
I am trying to set in order the Azure's Subscription of the company where I work. Long story short I have to deal with two Azure Active Directories. The first one is the main AAD (we will call it "MasterAD") where all the resources are deployed (servers, DBs, etc). The second one is a development purpose AAD ("DevAD"). In the DevAD there are two "App registrations" that we use to log in our clients in our web applications.
I would move those App registrations to the MasterAD. This way I could manage all the resources in one place without going around through ADs (and remember what is located where).
Is it possible to do that without changing the Application's IDs/Keys? I would not ask all my clients to grant again permissions for a "new" App registration.
You can't move the application object and keep the ids.
The ids will change.
I would do this:
Create new apps in MasterAD
Make sure all existing users are in MasterAD (as members or guests)
Change apps to use MasterAD instead with new client id / authority / keys
One thing to keep in mind that users' object ids are different in each directory.
One user added as a guest to another directory has a different unique id there.
If you have tied data to user object ids in a database etc., you'll have to prepare a migration to change those ids all at once.
I've installed WebSphere MQ 7.1 on Linux platform, after which I installed WebSphere Message Broker 8.0.0.1. Now when I try to create an execution group, I get an exception: Reason code 2035. This exception states that the user is unauthorised to connect to the queue manager. I have this user added in the mqm group. I did not face any such issue when I was working with MQ 7.0.x. I searched a lot and came to know that there is user ID blocking in MQ 7.1. But, I want this user to be able to create execution group, how can I do so? Please advise.
MQ security has been improved a lot in MQ v7.1 and is different from what it used to be in earlier MQ versions. In MQ v7.1, by default all SYSTEM.channels are blocked. If you are trying to use any of these SYSTEM. channels then you will get 2035 which is MQRC_NOT_AUTHORIZED. The recommended way is to create your own SVRCONN channel for broker and create channel authentication records to allow the user to access queue manager.
Please see this link for detailed answers from T.Rob on similar issue.
Update:
A SVRCONN channel defines the endpoint of a queue manager meaning the connection information required by the clients to connect to a queue manager. Client applications use this type of channel to send and receive messages to/from a queue or a topic.
Message Broker toolkit is GUI that you can use to administer message broker, for example creating execution groups, creating flow, deploying bar files etc. Toolkit is available on Windows and I guess it's available on Linux.
I got to know that MB toolkit requires SYSTEM.BRK.CONFIG channel which is a SVRCONN channel to connect to queue manager. I am thinking this is the channel you will need to authorize to allow Message Broker to connect to MQ. Can you check if this is the case and if so create channel authentication record for that channel?
If you create a new QMgr at V7.1 or above, it comes with the following default CHLAUTH rules:
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
DESCR(Default rule to allow MQ Explorer access)
ADDRESS(*)
MCAUSER( ) USERSRC(CHANNEL)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
DESCR(Default rule to disable all SYSTEM channels)
ADDRESS(*)
MCAUSER( ) USERSRC(NOACCESS)
SET CHLAUTH(*) TYPE(BLOCKUSER)
DESCR(Default rule to disallow privileged users)
USERLIST(*MQADMIN)
The one on the bottom tells the QMgr "if someone tries to connect over a SVRCONN using an administrative user ID, block the connection in all cases."
To allow a connection from Broker Toolkit you have two choices as follows:
Remove mqbrkrs from the mqm group. This allows it to connect without firing the CHLAUTH rule that blocks admin users. You will of course be required to grant authorization for the mqbrkrs group to all the broker and application queues to which it needs access since it is no longer an MQ admin.
Override the CHLAUTH rule to allow the broker toolkit to connect as an admin on the SYSTEM.BROKER.CONFIG channel.
As a security specialist, I favor the first option. It is unavoidable that the MQ admin can administer the broker. However it is possible to avoid allowing the broker (and by extension all the broker flows) to administer the QMgr.
If, however, you wish to take the second route you'll need to override the CHLAUTH rule that blocks admin access. There are several ways to do this. You could delete the rule but that opens all your channels to admin connections. A more precise approach is to provide a rule just for the channel on which the administrator is to connect. For example:
SET CHLAUTH(SYSTEM.BKR.CONFIG) TYPE(BLOCKUSER) +
USERLIST('*NOACCESS')
Since WMQ applies the most specific rule, the default rule is overridden by the new one but only for the SYSTEM.BKR.CONFIG channel. The BLOCKUSER rule syntax allows us to specify who to deny but not who to allow and it takes user IDs rather than group IDs. In order to allow admin access it is necessary to specify some ID that is not *MQADMIN. I picked *NOACCESS because it cannot be an actual user ID and is a reserved word used by WMQ elsewhere. You could as easily used any user ID such as nobody or even mqm. (Blocking mqm would allow mqbrkrs but not mqm however since mqbrkrs is in the mqm group it would not restrict mqbrkrs from administering the QMgr.)
Finally, note that any channel which allows admin access should be strongly authenticated. If the only CHLAUTH rule you set is the one above, then anybody with a network route to the QMgr can connect on that channel by asserting the mqbrkrs user ID on the connection. Once connected, they would have full control over the QMgr and the ability to remotely, anonymously execute commands using the mqm or mqbrkrs user IDs. At the very least add a CHLAUTH rule to filter conenctions on this channel by IP address. Or, even better, use SSL and filter connections by the certificate distinguished name.