How to protect access to /metrics and /health in Helidon MP? - helidon

/metrics and /health are usefull endpoints in Helidon MP but can disclose too much information publicly
Is there a way to protect access to those endpoints ?
With login/password or IP whitefiler ?
I didn't find anything on this in /metrics and /health documentation, stackoverflow.

The security section in Helidon docs describes how you can protect your endpoints through one of the various auth integrations. Authorization is a vast topic, choose your poison wisely!

Related

Google Cloud API Gateway - Security Features

I looked through all the documents of the API Gateway but was not able to find any reference of the security features that Google API Gateway provides - for example does it provide any protection from DDOS attacks, or OWASP security features. Any guidance will be helpful.
It seems you got confused between API Gateway and Cloud Armor.
Cloud Armor is the one that protects you from DDOS attacks. You can also find the documentation here.

Connection between the Traffic Manager and the Endpoint system in Mashery API Management solution

I would like to know if it is possible for Mashery solution to expose backend services that are secured with OAuth 2.0 or Kerberos.
My idea is to hide this authentication by Mashery Traffic Manager, for the services that are secured with a basic authentication it works very well but for the rest I do not have connectors on my administration panel.
Thank you for your answers.
Apart from regular open ones and endpoints with API key authentication where key is passed as a query parameter(or feasible urlpath), as of now Mashery can handle the backends with Client SSL Certificate and HTTP Basic Authentication only, which you can set in in 'Security Settings' of the endpoints.
No oAuth2.0 is possible and I don't think they have any plans to implement it in recent future.

API security in Azure best practice

I'm developing a web API that will be called by other web apps in the same Azure host and also other 3rd party services/ app. I'm currently looking into API Apps and API management, but there are several things unclear for me regarding security implementation:
Does API App need to have authentication when implemented with API management? If yes, what are the options? This link http://www.kefalidis.me/2015/06/taking-advantage-of-api-management-for-api-apps/ mentions "Keep in mind that it’s not necessary to have authentication on the API App, as you can enable authentication on API Management and let it handle all the details." So that means having the API App authentication to public anonymous? But then someone who knows the direct URL of the API App can access it directly.
What is the best way to implement API Management security? The one mentioned in the tutorial (Having a raw subscription key passed in the header) seems to be prone to man in the middle attack
What advantages does API App add instead of implementing with normal Web API project?
Thanks in advance.
I can answer from API Management perspective. To secure the connection between API Mgmt and your backend (sometimes called last-mile security), there are a few options:
Basic Authentication: this is the simplest solution
Mutual certificate authentication: https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/ - this is the most common approach.
IP Whitelisting: if you have a Standard or Premium tier APIM instance, the IP address of the proxy will remain constant. Thus you can configure firewall rules to block unknown IP addresses.
JWT token: if your backend has the capability to validate JWT tokens, you can block any callers without a valid JWT.
This video might also be helpful: https://channel9.msdn.com/Blogs/AzureApiMgmt/Last-mile-Security
I think the document meant you can do the JWT token validation in APIM. However, to prevent someone calling your backend directly, you'll have to implement one of the options mentioned above in your Api Apps

How does a server discover an OpenId Provider's authentication's endpoint?

If a person enters in their OpenId authentication provider as: http://www.myopenid.com ... how can I discover that the real endpoint I need to 302 redirect them to is https://www.myopenid.com/server ?
BTW: I only know https://www.myopenid.com/server is the endpoint because I've been manually snopping the traffic in my browser (eg. when I attempt to login in on StackOverflow via their MyOpenId icon/pic).
Any clues, please?
OpenID 2.0 Specification explains the discovery process [1]. There are three discovery methods discussed in the specification.
XRI Resulution
Yadis Protocol
HTML Based Discovery
The libraries you are using to implement the OpenID Relying Party should be supporting these methods, so they would calculate the OP endpoint.
[1]. http://openid.net/specs/openid-authentication-2_0.html#discovery

JAX-RS access control

Can some one provide me some pointers about access control in JAX-Rs web services. e.g. limiting access on the basis of user credentials, or name or any other criteria. Could not find any useful information in the sun manuals.
Thanks in advance,
Adhir
I personally use Spring security to accomplish this. Spring security allows for easy use of various authentication and authorizations schemes (E.g. by checking the basic/digest headers from the HTTP request against a database or LDAP server). It's not to hard to set up with JAX-RS and also has a nifty aspect based rights system where you can do stuff like
#PreAuthorize("hasRole('ROLE_ADMIN') or order.customer.username == user.username)
deleteOrder(Order order);
which ensures that a authenticated user must either be in the ROLE_ADMIN group or be the owner of the order to be allowed to delete it.
When this is configured all you have to do in your JAX-RS resource is to handle the Security exception from spring and take the appropriate action (fx. by throwing a WebApplicationException as described here)
There are many ways that people have accomplished this and there are a number of great threads on the topic on this site (see Best Practices for securing a REST API / web service)
I personally use OAuth to accomplish this task. For more information on OAuth check out Beginner’s Guide to OAuth