we are using Anypoint MQ. We are looking for options to configure access to individual queues exclusively, so that they are accessible to only certain apps. But, based on our research it looks like - with anypoint credentials we can browse messages from all the queues.
Can you please help us if exclusive queue access credentials can be configured? Thanks for your help!!
You can use business groups or environments to restrict access according to the FAQ: https://docs.mulesoft.com/mq/mq-faq#how-can-i-restrict-access-to-a-queue-or-message-exchange
Related
Looking for documentation on our overall networking for WKC on Cloud in order to feel confident in its viability & security. Want to know all connectivity and networking options for WKC.
The recommended way is to use the IBM Cloud Secure Gateway service. WKC has direct support for it.
Here are the docs
for creating a connection.
Here are the docs
for configuring a secure gateway service.
Here are the docs
for all connections available out of the box in WKC.
How can we configure OpenStack to use and dynamically update remote Bind DNS Server.
This is not currently supported. There is a DNS driver layer, but the only driver at the moment is for LDAP backed PowerDNS. I have code for dynamic DNS updates (https://review.openstack.org/#/c/25194/), but have had trouble getting it landed because we need to fix eventlet monkey patching first.
So, its in progress, but you probably wont see it until Havana is released.
OpenStack relies on dnsmasq internally.
I am not aware of any way integrate an external bind server. Or plans to do that. Or even a reason to do that.
Check out Designate (https://docs.openstack.org/developer/designate/)
This could be what you are looking for:
Designate provides DNSaaS services for OpenStack:
- REST API for domain & record management
- Multi-tenant support
- Integrated with Keystone for authentication
- Framework in place to integrate with Nova and Neutron notifications (for auto-generated records)
- Support for PowerDNS and Bind9 out of the box
Has anyone experienced running multiple collaborating applications on Heroku? For example, an admin application to manage another application; or a stats server observing another application?
On Amazons' EC2 platform you can use security groups to restrict access to servers, creating a virtual network between your application or server instances. Is there any such way to do this on Heroku? If so, can you open UDP as well as TCP connections?
Thanks
Robbie
The comment from #elithrar is correct. To talk between applications you either need to define an API, or used shared resources. For example you can have 2 applications connect to the same database by manually copying and pasting the DATABASE_URL from one app to another. This has the downside that should we need to roll credentials (very rare) your manually copied configuration will break.
The same pattern can be used with any add-ons, such as https://addons.heroku.com/redistogo or https://addons.heroku.com/iron_mq to share a message bus or queue between two applications.
I have a two node BTS2010 group with a separate SQL Server hosting the BTS databases including SSODB; Biz01, Biz02 and Sql01. This environment was configured by a previous employee and I have no documentation available.
There seems to be something not right with the SSO config but I'm not sure how to resolve it.
When I run ssoconfig -status on Biz02 all looks good - it tells me that the SSO Server is Biz02 and the SQL Server is Sql01 plus a load of other stuff. However, when I run the same command on Biz01 I get the message: "Error 0xC0002A0F: Could not contact the SSO server 'Sql01'. Check that SSO is configured and that the SSO service is running on that server'
I'm not clear on what Biz01 is trying to do here - is it trying to reach the EntSSO windows service on Biz02 via an RPC call, before ultimately attempting to retrie config info from Sql01?
I have checked that the ENTSSO service is running on Biz01, Biz02 and that the RPC service is running on each of the three servers.
Can anyone help advise what further steps I can take to determine the root cause of this configuration problem?
Many thanks
Rob.
I'm not sure if you have your servers clustered or not but I've run into something similar before within a cluster. Your SSO name should be your network name and not the individual computers name. Here's an post about the issue I had. Hope it helps.
Microsoft's Enterprise SSO server is bundled with BizTalk Server - I'm fairly familiar with how to configure it, make sure it's working, etc. My questsion is, what exactly does it do, and how does it do it?
My best understanding is that it is used to securely store configuration for things like ports and adapters, because configuration items often include things like credentials, passwords, connection strings, etc. In terms of "how it works", my best guess is that the configuration values are stored encrypted in an SSO database, and the "master secret" is simply the encryption key that only privileged credentials (like the one running the BizTalk hosts) have access to, so they can use it to access the encrypted configuration.
Can someone shine some light on this and point out where this is right/wrong?
You're pretty close overall. EntSSO is used by BizTalk internally to store any sensitive data. This includes particularly the adapter-specific part of any send port/receive location configuration.
But that's not all EntSSO does; it can also be used to provide credential mapping services between Windows and non-windows systems, by storing sets of encrypted credentials for other applications and mapping within them. Basically, this can be used to provide single sign-on services when building BizTalk solutions so that BizTalk can "act as" a specific user when doing stuff on their behalf.
For example, you could have BizTalk receive a message over an HTTP/SOAP receive location set up with Windows Integrated authentication, and then let BizTalk flow that authentication information over to an FTP send port where the Windows user credential is mapped to a specific username/password combination associated to it so that BizTalk can authenticate as said user to the FTP server. With this, different Windows Users sending messages to BizTalk would result in separate FTP connections created with different credentials on the other end (this is different from the default BizTalk behavior of using a single credential for all operations on a send port).
Obviously EntSSO offers a bunch of other options beyond this, but that's kinda the big deal.
BTW, the BizTalk docs actually contain a fairly extensive section on EntSSO that is pretty useful.