We are using AEM as content service and exporting AEM content into mobile application. For example below api will be used in mobile application and Mobile application will build the presentation layer.
/content/we-retail/us/en/products/women/shirts/jcr:content/root/content-tile.model.json
Here I basically want to authenticate AEM API before I serve the json response. In essence, I want to only accept requests from mobile applications. I should the request If anyone else calls AEM.
I am planning to use an SSL client certificate to confirm that the request is valid. I am confused who generates the SSL certificates. Is it something mobile application generates the certification and dispatcher use and add the certification. or the opposite way, AEM to generates the certificate and mobile application use
This is a little unclear. Could someone please explain to me who should create the certification file?
Related
In our current project, IT rules prohibit anything that is not PROD to be publicly accessible from the Internet. Access to development and review environments must be severely restricted. That said, the project also includes mobile apps that are developed together with the cloud-hosted API layer.
In very general terms, what are the common approaches to securing DEV / REVIEW-stage APIs with mobile apps? We've come up with the following ideas:
IP whitelist on the ingress to the API (least secure, but easiest to use)
VPN gateway to the hosting environment, with corresponding DEV / test devices configuration
Mutual TLS authentication (most difficult to implement and operate)
There are multiple issues to address with each one of the approaches, but I'd like to understand the big picture before diving into any of that.
IP Whitelist
IP whitelist on the in the ingress to the API (least secure, but easiest to use)
I see it as least secure if you are whitelisting IPs that are not exclusive to your company office and/or the the IP is exclusive to your company but used by public WI-fis in your company.
Also in the case you need to whitelist access to remote developers and testers that may or not be in a public IP, this solution will be risky, because people always put convenience in front of security and they may ask to whitelist IPs that are from the coffee shop they like to work from, the shopping mall, the girl friend home, etc..
So I would discard this option, unless you are in a small office where you have the public WI-fi(the one for your clients to use) in a different IP from your main internet connection.
VPN Gateway
VPN gateway to the hosting environment, with corresponding DEV / test devices configuration
This approach seems to be the much wise to follow and only who have been granted access to the VPN will be able to use resources hidden behind it, and VPNs can be even used in public WI-fi.
Mutual TLS Authentication
Mutual TLS authentication (most difficult to implement and operate)
While is difficult to implement and operate they also suffer of the problem of certificate pinning be possible to bypass.
On this article about pinning in mobile apps we can read how easy it can be to implement certificate pinning:
// simplified android example
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("publicobject.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
.add("bikewise.org", "sha256/x9SZw6TwIqfmvrLZ/kz1o0Ossjmn728BnBKpUFqGNVM=")
.build();
OkHttpClient client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build();
In this same article we can also see how pinning can be a nightmare... as you said, difficult to operate!!!
The main difficulty with pinning is not technical but operational. By embedding fixed information about the server (the certificate) into the app you create a dependency between the two, as the term pinning implies. This means that whenever you (or your ops team) are planning to change the certificate on the server you must:
Generate the certificate in advance
Build, test and publish a new version of the app with both the new certificate and the old one.
Wait for most (80%, 90%, 99% ?) of your users to upgrade to the new version
Change the cert on the server
Build, test and publish a new version of the app with the old certificate removed.
As if this was not enough, certificate pinning can be by passed by using introspection frameworks, as pointed on the same article I linked above:
Even if you successfully navigate the operational difficulties inherent in implementing pinning, there is still the giant pink elephant in the room that is unpinning. The development of hooking frameworks such as Xposed has reached such a level of sophistication that a rich ecosystem of modules exists to target various aspects of Android apps including the pinning functionality of HTTP libraries. Using them is very straightforward.
Another Approach - Going the extra mile
That said, the project also includes mobile apps that are developed together with the cloud-hosted API layer.
In the context of a mobile apps you can use a technique devised as Mobile App Attestation, that can be used across all environments to protect the API server, for the mobile apps, from responding to requests that are not originated from the genuine mobile app binary you released, signed and registered for that specific environment.
Mobile App Attestation
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device. It consists of a SDK integrated in a your mobile app that runs in the background, without impacting the user experience, and communicates with a service running in the cloud to attest the integrity of the mobile app and device is running on.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
The mobile app must send the JWT token in the headers of the request for very API call it makes. This allows the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Anyone trying to verify at run-time if a JWT token issued by the Mobile App Attestation is a valid or invalid one will not succeed, because the only difference between them is the secret used to sign it, and this secret is only known at anytime by the Mobile App Attestation service and the API server. This means that even the mobile app is not in possession of the secret, thus is not aware if is sending a valid or invalid JWT token to the API server.
Conclusion
From your 3 solutions I would go with VPN approach and if you would want to go for the extra mile you should consider implement your own Mobile App Attestation service to guarantee that mobile APIs for any environment only communicate with mobile apps for that specific environment/stage and deny requests from any other source. This solution even allows for your mobile API to be hosted on the public domain without risking leaking any data, thus not needing a VPN on front of it.
Am using IBM Worklight Studio 6.1.0.02-20160314-1430
Its Hybrid application.
Request and Response data between app and adapter calls is clearly getting visible when do inspect(Network-->query) in an application. Its also possible to edit request or response parameters by interrupting worklight app using third party tool like Charles. Implemented SSL pinning in the application but some how SSL pinning also breakable as lot of tools already available in online. Is Worklight giving any encrypt-decrypt mechanism for request and response parameters which is communicating between adapter and app.
Currently I tried adding custom encryption from app side and custom decryption at adapter side for request parameters. This is very tedious process as my app having hundreds of procedures. Please let me know any centralized security I can implement so that request and response should not be visible anywhere between app and worklight server even if someone inspect also.
When you redirect your traffic through a proxy such as Charles , it is expected to see communication in plain text. In this scenario you configure the setup by accepting certificates issued by Charles and modify your application to direct communication via Charles. You will not see your data in plain text if you try to sniff an on-going SSL traffic.
That said, certificate pinning feature is available out of the box starting MFP 7.1 onwards. Certificate pinning is done before making any calls to the server and as such all your communication can be secured.
You already seem to have adopted the other approach of encrypting parameters at the client and decrypting later at the server. In case you have many adapter invocations, you can have a single method that produces encrypted content and all your adapter invoke parameters can be passed through this.
Say, for example, I have an Azure web app named MyApp and is hosted on Azure as MyApp.azurewebsites.net. It's my understanding that there is nothing I need to do to secure the URL with SSL, as it's done, by default, with a single certificate. So I can already have my users access the app via https://MyApp.azurewebsites.net, and it will be secure right out of the box.
However, say I have another URL named www.MyApp.com that I want to point (redirect) to https://MyApp.azurewebsite.net. Do I have to secure www.MyApp.com with a certificate?
Do I have to secure www.MyApp.com with a certificate?
Yes, we could get more detail info from the official document .
To secure your custom domain name with HTTPS, you bind a custom SSL certificate to that custom domain in Azure.
Before binding a custom certificate, we need to do the following:
Configure the custom domain - App Service only allows adding a certificate for a domain name that's already configured in your app. For instructions, see Map a custom domain name to an Azure app.
Scale up to Basic tier or higher App Service plans in lower pricing tiers don't support custom SSL certificates. For instructions, see Scale up an app in Azure.
Get an SSL certificate - If you do not already have one, you need to get one from a trusted certificate authority (CA).
Yes, if you use a custom host name, then you will need to have a certificate for it. There is really no way around this, based on how SSL works.
I have a Ruby on Rails app running on Heroku server. As I'm testing the app with SSL certificate, I added a non-paid one like this tutorial explains, and forced the server app to use SSL with RackSSL gem.
So, I also have an Android client and I have some doubts:
How do I verify if the client request is using the same certificate?
How do I force SSL only on specific Rails routes?
Thanks in advance!
Ad. 1, do as suggested in the guide: Visit the endpoint and look at the certificate that gets served up (it should be the one you added). Note that the certificate is not different depending on the client accessing Heroku, it's something that Heroku serves up to clients accessing the endpoint so you can verify this using either a normal desktop browser or your smartphone.
Ad. 2, check out this answer which suggests rack-ssl-enforcer.
Does anybody has a WebLogic 8.1 two-way SSL full example?
I am developing a small web application (1 HTML, 1 Servlet, 1 JSP) to send confidential data. The client could be a web browser. The server is WebLogic 8.1.
The information should travel encrypted. Besides, the web application needs to authenticate the client, using more than a username/password combination. I thought implementing using HTTPS and two-way SSL authentication. This way, the user should send me her certificate, I installed in the server, so the web application could know when it is sending information.
Now, I know how to use declarative authorization in a web application, but I am lost on how specify which users I recognize, and which are their certificates.
I just need a full example of this. A .war and/or the steps to do the basic case.
I don't think you'll find a full example easily and the question is a bit broad. But the link your provided is a very good starting point.
First configure Two-Way SSL and use CLIENT-CERT. Clients will need to buy a trusted client certificate or to generate a self-signed certificate that you'll need to add to the server trust store. This may be the hardest part if you're not familiar with PKI but I've added resources at the end of this answer that cover this part. Load the client certificate in each client browsers.
Second, configure an Identity Assertion provider to map the digital certificate of a Web browser to a user in a WebLogic Server security realm. If required, provide your own user name mapper or use the default one (which uses the attributes from the subject DN of the digital certificate or the distinguished name to map to the appropriate user in the WebLogic Server security realm).
Third, add users corresponding to the Subject's Distinguished Name (SubjectDN) attribute in the client's digital certificate in Weblogic Security Realm and assign them to groups.
Finally, use these groups in your declarative authorizations.
Sure, it won't be that easy if everything is new but that's basically what you need to do. Maybe start to implement it and open more specific questions if you need more guidance.
More resources:
Two-Way SSL in Weblogic for Developers
The Fifteen Minute Guide to Mutual Authentication
Certificate to User Mapping in WebLogic
How to Set Up X509 Certificate Authentication for Oracle WebLogic Server (transposable to WLS 8.1)