I have an existing site which I want to use APIM with and I have successfully mapped my APIs across to APIM. However, I have a swagger page which I just want to be available in the same domain as APIM. How can I do this? The swagger page is:
https://mysite.azurewebsites.net/api/swagger/index.html
I want this to come across as something like
https://myapidomain.com/swagger
My apis in APIM are of the form so I want the swagger to match the same domain
https://myapidomain.com/api/myfirstapi
This can be done with a few caveats depending on how complex your web page is:
Create an API with URL suffix of "swagger"
Optionally uncheck "Require subscription" from that API to make it anonymous
Create inner operation with URL template of "/" and GET method
Add policies to operation inbound:
<set-backend-service base-url="https://mysite.azurewebsites.net" />
<rewrite-uri template="/api/swagger/index.html" />
Test and adjust
That will take care of the page itself. There will be problems if page uses cookies or references external scripts/images via relative URIs. Cookies will be a problem because they'll come with domain set to "mysite.azurewebsites.net", so you need to take care of this in policies.
Resources with relative URLs are problem because browser will make additional requests to your APIM service with those URLs, so you'll need to create additional operations to cover those requests. Using * in operation template might help cover multiple resources.
Related
I can’t seem to figure out how to use two different IDPS and 2 different applications URLs. I had this working on weblogic but not with a spring boot application using the spring saml security.
One important part is that we have two different URLs.
Proxy URL for external users. They must use this URL as they are not in the network.
a. These users hit IDP-A
Internal URL for internal users.
b. These users hit IDP-B
The metadata we sent to the each of the IDPs use the same entity ID but different endpoint URLs.
One thing we did was turn on discovery and where able to hit each IDP but it always redirects us to the internal URL. I noticed that AssertionConsumerServiceUrl is always set to the internal URL, which explains why it is returned to is the same. In our weblogic implementation we do not send AssertionConsumerServiceUrl.
Can we exclude AssertionConsumerServiceUrl?
Do you know if the configuration I am attempting to do is even possible?
you can autowire the MetadataManager bean in your service and then call the addMetadataProvider to inititate a metadata.
You can get the entityId from the Metadata Obtained from IDP and can append to the url :
'http:///saml/login?idp=' by hitting this url it will redirect you to appropriate IDP login.
Is there any way to disable the authentication requirement for accessing the API Documentation endpoints provided by the apiDiscovery-1.0 feature?
I have the apiDiscovery-1.0 feature enabled on Liberty 16.0.0.4.
I am able to see the swagger documents when I access /ibm/api/explorer as expected, but I am required to authenticate.
I am only able to authenticate by using credentials defined in a basicRegistry element within my server.xml. However, I want to eliminate this basicRegistry from my server configuration.
You can do that in the latest Beta (https://developer.ibm.com/wasdev/downloads/liberty-profile-beta/)
With that driver, you only need apiDiscovery-1.0 (SSL is optional).
The default address for the public endpoint is http://host:port/api/explorer
You can change the "/api" portion by using the publicURL attribute in the apiDiscovery element in server.xml, for example:
<apiDiscovery publicURL="/myPublicAPI" />
This is targeted for Liberty's next release, 17.0.0.1.
Please note that in the public endpoint, internal endpoints (such as JMX, Batch, etc) are not displayed - only your deployed applications.
For the internal endpoints, you can use /ibm/api/explorer (which remains requiring SSL and authentication).
I believe you can't remove the requirement for authentication for apiDiscovery for security reasons.
I doubt this helps but, you shouldn't "only be able to authenticate using credentials defined in a basicRegistry element within my server.xml" and instead any supported authentication mechanics should work like quickStartSecurity, LDAP, etc (and they can be set in any configuration file that is read by the server, not just server.xml). For example, you should be able to use quickStartSecurity in wlp/usr/shared/config to apply an Admininistrator role for all servers under that /wlp/usr/servers/ directory.
I am preparing to work on a project where I need to display a dashboard from an online application. Unfortunately, the use of an API is currently not possible. The dashboard can be embedded in an iFrame. However, when it is displayed it will prompt the user viewing the dashboard to login to an account.
I have one paid account to this service. Are there any rails gems to login to the service before the iFrame is processed?
Or would a proxy within my rails app be a better route to go?
Any pointers are appreciated!
Neither a Rails gems nor a proxy within your rails will work and they same have the same limitation.
They are both running on the back-end, server side.
The authentication you need is client side.
Unless you mean proxy the ENTIRE thing, the auth request and all subsequent requests and user interactions with this dashboard. That should work but (see below)
The way authentication works (pretty much universally) is: once you log in to any system, it stores a cookie on your browser and then the browser sends that cookie for every subsequent request.
If you authenticate on the backend, that cookie will be sent to your rails code and will die there, and the users browser will never know about it.
Also - it is not possible to do the auth server side and capture the cookie and then have the user browse the site with their browser directly, for two reasons:
Sometimes auth cookies use information about the browser or HTTP client to encrypt the cookie, so sending the same cookie from a different client wont work
You can not tell a browser to send a cookie to a domain different than your own.
So your options are, off the top of my head right now:
If there is a login page that accepts form submissions from other domains, you could try to simulate a form submission directly to that sites "after login" page. (The page the user gets directed to once they fill up the login form). Any modern web framework as XSRF protection (Cross Site Request Forgery protection) and will disallow this approach for security reasons.
See if the auth this site uses has any kind of OAUTH, Single Sign On (SSO) or similar type of authentication integration that you can do. (Similar to an API, so you may have already explored this option)
Proxy all requests to this site through your server. You will have to rewrite the entire HTML so that all images, CSS, stylesheets, and all other assets are also routed through the proxy or else the URLs are rewritten in the HTML to not be relative. You might hit various walls if a site wasn't designed for this use case. From things like the site using relative URL's for assets that you aren't proxying, the site referencing non-relative URL's causing cross-domain errors, etc. Note its really hard to re-write every single last assets reference, its not only the HTML you're worried about, Javascript can have URL's in it too, and CSS can as well.
You could write a bookmarklet or a browser extension that logs the user into the site.
Have everyone install Lastpass
Have everyone install the TamperMonkey browser extension (and others like it for other browser), and write a small User Script to run custom javascript automatically to log the user in on that site
Scrape that site for the info you need and serve it on your own site.
OK I'm out of ideas. :)
I am developing an Online Recruitment System in Java EE using Servlets and I want to give each user his own unique url by adding username to context path using '/'.
Simply put I want to rewrite my url from /main to /main/username so when people login they can see their username in address bar(just like at stackoverflow or facebook).
Eg. Currently I am redirecting to "/main?username="+username (works fine) using Jquery Ajax but I want to redirect to /main/username.
I tried encodeURL method but '/' makes search for into subdirectory. If anybody think it should work, please give me the syntax.
I have done url mapping in web.xml.(Eg. signin.jsp is mapped to signin uri)
If I understand your question, you want to have a Java EE site like myrecruitingsite.com where you can redirect a user to myrecruitingsite.com/main/<username>. When a request is made to myrecruitingsite.com/main/arg21, or myrecruitingsite.com/main/geoffreywiseman, you'd want the request to go to the same servlet, and you'd like to know which username was requested.
Java servlet mappings don't directly support complex routing patterns in the way that many modern web frameworks do. You can't configure the web.xml to send a request from myrecruitingsite.com/main/<username> to the user profile servlet and myrecruitingsite.com/main/<username>/contact to the contact servlet. You can do wildcard mappings, but all the routing decisions after that you'll have to do outside of the web.xml.
Alternately, you can do URL rewriting (typically with servlet filters) such that the URL requested by the browser is not the final one interpreted by the servlet mapping layer. There are frameworks for this, or you can do it yourself.
Basically, you need to configure the servlet mapping's url pattern with a wildcard, and then query getPathInfo() to find out what the rest of the wildcard was. That alone is pretty simple.
If you're using any one of a wide array of Java web frameworks, there will be facilities for routing and quite possibly a front controller servlet that does what you need already. In that scenario, you'll need to look at the framework's documentation for more information.
On the other hand, if you're doing it yourself using servlets (or even servlets + jsp), you can either just do a wildcard mapping to a single servlet that will grow larger and larger as you add more features to it, or more likely, you'll need to develop your own micro-framework where the servlet acts as a Front Controller servlet and does the routing work and delegates all the subsequent work to plain old java objects (POJOs).
By way of example, your routing servlet could maintain a mapping between url patterns (perhaps specified in java regular expressions) to objects of your own creation that either mimic the servlet interface or another interface of your own creation. That way, you have a servlet that's responsible for the routing decisions bound in the web.xml, and a network of little classes that are responsible for the specifics of a particular request. It's work, but it's not terrifically difficult.
Usually this is achieved using url rewrites on the server. For IIS that means creating a web.config or in apache creating a .htaccess file. You'll need to find the equivalent for your server and it can then be made to parse the directory structure type /username/ into a HTTP GET variable for your application.
I tried looking up any tips for restricting access to static content/partial urls on a web server for my grails web-app but getting confused about using element in web.xml, since right now I am using the grails default jetty server (doesn't use web.xml) and the images, css, js etc are all accessible without any authentication. how do I go about restricting access to
1) all static content directories - only accessible in a valid user session.
2) all intermediate url paths not displaying content in the appropriate format/incorrect content.
It should say like not available/forbidden if the user tries to access above 2 by hitting urls.
Implement your own filters (by URI) in grails-app/conf. For more details see section 6.6 Filters in grails documentation
... off the top of my head I'd try the spring-security plugin, it has options for restricting access on per url basis. Good start is here the screencast