I have configured a notification hub using Azure portal for implementation of push notifications for mobile apps. On navigating to the Access Policies section, I see couple of policies with names: DefaultListenSharedAccessSignature and DefaultFullSharedAccessSignature as shown in the below diagram. Both the policy names contain connection string. One of the connection string is as follows:
Endpoint=sb://expedia.servicebus.windows.net/;SharedAccessKeyName=DefaultFullSharedAccessSignature;SharedAccessKey=JnVgQvxxxxxxxxxxxxxxxxxxxxxxxy1HgWUfUo=
I want to understand what is sb protocol here and want to how it works internally and does it depends on HTTPS.
I have to access the above endpoint from a remote server. How to consider the above while white listing the proxy rules to allow access to the above endpoint.
sb is just an endpoint schema that we understand, and it's not an actual protocol. The actual protocol is https.
According to a more broadly framed Service Bus FAQ, they detail the ports that are used by sb:// which uses both HTTPS (443) and AMQP (5671, 5672)
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-faq#what-ports-do-i-need-to-open-on-the-firewall--
Related
use case
in icCube
one server instance
icCube users only need to access the reporting
icCube is used to for a standard reporting solution for an industry vertical and can be used by multiple clients, each having their own (copy of the) structures that work with their own data
a client can grant one or more users access to their own dashboards in icCube
authorization requirement
it should be possible to link authorization to the client's identity
management system (such as AD)
for others, it should be possible to assign a local admin at the client that can give access to their own environment to whom they wih
for the rest, it should be possible for a centralized admin to maintain access
a perfect job for ...
keycloak
keycloak needs for each of the requirements a seperate realm with client (see picture)
The icCube documentation only makes mention of one Realm & client.
the question
Is it possible to use multiple keycloak realms & clients with one instance of icCube?
See also icCube documentation on keycloak integration
Right now this is not possible.
The keycloak.json file is used to connect to a Keycloak server that is going to authenticate the HTTP request. So you would need somehow a way to determine which keycloak.json file to use based on the HTTP request before using it meaning having different URL and/or URLs with a specific parameter.
Possibly the multi-tenant support could be extended to be able to configure an authentication logic per tenant with the same constraint about the URL value.
Hope that helps.
I am developing a web application where data will be accessible both to frontend and to various clients (curl & co.) through REST API. Both frontend and backend will be on the same domain. I would like to protect my frontend with CORS, which presents a dilemma for me. If I set Access-Control-Allow-Origin to * then all other clients will be able to access API, but my own frontend will be more exposed. On the other hand setting it to my domain forces clients to supply (fake) Origin headers and effectively disallows using browsers as clients (via frontend on different domains).
How is this usually solved? Should I use two different endpoint for API, one for public access and the other for use with my frontend? I would appreciate some advice.
I would like to protect my frontend with CORS
CORS doesn't protect anything in the frontend, CORS is a way to prevent cross-site scripting from web sites which are not authorized. The CORS headers are effective only for browser's XHR calls. It will not prevent direct loading of resources.
If I set Access-Control-Allow-Origin to * then all other clients will be able to access API, but my own frontend will be more exposed.
IMHO you frontend will be accessible as before. The CORS headers are effective only for browser's XHR calls
On the other hand setting it to my domain forces clients to supply (fake) Origin headers and effectively disallows using browsers as clients (via frontend on different domains).
Not really.
There are several options:
You can have a list of allowed hosts for each API client (effective you set the origin header based on the client's authentication) This is what many of API providers do (FB, Google, Amazon, ..)
the browser (in the XHR calls) sends the Origin header and you could check and sent or deny the hostname from the Origin header
And non-browsers clients are not restricted by the CORS headers.
Should I use two different endpoint for API, one for public access and the other for use with my frontend? I would appreciate some advice
As written in the comments - assuming the functionality is the same and users are authenticated, then IMHO there is no point in having separate services for internal / public use.
These all are answers for particular questions, however I am still not convinced it is clear what/why/how you want to achieve.
CORS is relevant only for browsers & HTML. curl doesn't care about it. So if you restrict your service to be accessed only from your domain, then other sites won't be able to access it.
To make your service available for them - those sites could set up nginx or apache to forward some of the traffic to your service. So 3d-party sites will access their own host with their own CORS configured and their host will communicate with your service.
Another (similar) solution would be for you to set up 2 host names (subdomains?) that lead to the same service. And expose one to your own site (with strict CORS) and the other - for external clients.
I struggle around with CORS implementation in my client-server project. CORS means, that calls from other origins (ex. other domain) only allowed if the header contains the CORS value.
So, for example if I host a website on www.domain.com and call an RESTful API on the same domain, everything is fine.
But if I develop an API for an mobile application for example, the mobile does not have the same domain of the API. How could that work together? Does I need everytime the CORS implementation in my service?
The question comes up, since I develop an Angular 2 application, that is running in dev on localhost:4200 and my API runs on localhost:8080 (build with Spring Boot). So the client throws an exception, because it's not the same origin (different port).
The Goal is to host my API on an root server somewhere in the internet, and the client on different webspace provider (because it's just a single Page Application). The api runs with http://1.2.3.4:8080/api/v1 and the client with http://www.example.com:80/myPage
So, does I need to implement Cross-Origin everytime? Or is there another way to realize that?
Due to security concerns, browsers enforce same-origin policy i.e., a script (typically AJAX calls) running in a web page cannot access data from another page residing in a different domain. In some cases, this can be restrictive. CORS (Cross Origin resource sharing) is a W3C specification supported by most modern browsers to specify when it is safe to allow cross origin requests.
In Spring boot, enabling CORS is as easy as adding the #CrossOrigin annotation. This annotation can be added at method level to enable just for that particular request mapping or at the class level to enable for the whole controller.
You could list the domain and port to be allowed by adding an "origins" attribute to the annotation. If it is not specified, all origins are allowed by default (better to avoid this for security reasons).
Below is an example to enable CORS for example.com domain and port 80 at controller level
#CrossOrigin(origins = "http://www.example.com:80")
#RestController
#RequestMapping("/yourmapping")
public class YourController {
}
Yes, if you are developing an API and want to make it public and want mobile users or other site consumers use it, you should set CORS for any site (*) , always. You can read more info here:
https://spring.io/understanding/CORS (no longer functioning)
https://auth0.com/blog/cors-tutorial-a-guide-to-cross-origin-resource-sharing/
We have come across similar problem, need your help to resolve this.
Can you please either let us know your contact number so that we can reach out to you or if you can provide your script if possible so that we can refer to
Here is the problem we are stuck with:
I am trying to test a Rest service through HTTP sampler using Jmeter. Not sure how to capture token from the sampler generates a token and to use this token for authorization in the header manager of another HTTP.
Loadrunner is not displaying the web address when trying to enter in the truclient browser. Below is the problem as this web address automatically redirect to another web address which is the authentication server.
Can you please suggest another solution for the below issue?
Here is the exact scenario we are trying to achieve
we want to loadtest the portal however due to redirect and different authentication method being used we are unable to do it using truclient protocol in loadrunner. Also tried Multiple protocol selecting LDAP, SMTP, HTTP/HTML etc but no luck.**
Thank You,
Sonny
JMETER is going to architecturally be the HTTP protocol layer equivalent with LoadRunner, with the exception of the number of threads per browser emulation.
In contrast to the code request, I want to architecturally visualize the problem. You mention redirect, is this an HTTP 301/302 redirect or one which is handled with information passed back to the client, processed on the client and then redirected to another host? You mention dynamic authentication via header token, have you examined the web_add_header() and web_add_auto_header() in Laodrunner web virtual users for passing of extra header messages, including ones which have been correlated from previous requests, such as the token being passed back as you note?
This authentication mechanism is based upon? LDAP? Kerberos? Windows Integrated Authentication? Simple Authentication based upon username/password in header? Can you be architecturally more specific and when this comes into play, such as from the first request to gain access to the test environment through the firewall or from a nth request to gain access within a business process?
You mention RESTFul services. These can be transport independent, such as being passed over SMTP using a mailbox to broker the passing of data between client and server, or over HTTP similar to SOAP messages. Do you have architectural clarity on this? Could it be that you need to provide mailbox authentication across SMTP and POP3 to send and receive?
I am working on xmpp protocol and I came across with Gateway concept, in which it allows to communicate to services which uses another protocol like msn,aim,yahoo etc ..
As far as I understand I beleive that it allows only 1 registration for a particular gateway at a time.For example I can register only 1 msn account at a time.I'am not sure if its really true.
Is it possible to register more that 1 account for a particular gateway and how?Please help me with this..
That is true. All gateways I know (e.g. spectrum) only allow one registration per instance. But you can run multiple instances of the smae gateway type e.g.:
icq1.jabberserver.com
icq2.jabberserver.com
That is, additional to run mutliple gateway components to different IM neworks, like
gtalk.jabberserver.com
irc.jabberserver.com
icq.jabberserver.com
msn.jabberserver.com
...
you also run multiple instances of the same gateway component on your server. Please not that this are (internal and/or external) components to your XMPP server and not individual XMPP servers!