I have a internal PKI which issues certificates for two types of end entities. First is a group of IoT devices and second is for few web applications. Subject name of the former will be X.500 DN, whereas the later contains dns address of the web application. How does an application (Relying party) validates the use(IoT device or Web application) of the target certificate? One way is to use initial-permitted-subtrees (refer RFC5280) with empty name types. Other way i thought is to create two different policies for the two certificates types and user-initial-policy-set as a filter. But is it valid to have two different policies for one PKI? Which of the above two ways is more meaningful? Are there any efficient methods apart from this?
Related
Let say we are build an ecommerce application for web and mobile using REST API with Admin, Merchants and customers roles using Laravel/Lumen.
Is it a good best practice to have separated application for each roles with single database?
One application will usually suffice. It is usually best practice to have a single API (or a single set of microservices) where endpoints enforce your security policies for each role - rather than separate services for each role. This is more maintainable because these services typically share a lot of logic.
On the front end, it may be a different story. You might want a separate Admin app that has such different functionality that it makes sense to build it separately.
Use case
I am building a webshop where people can register/sign in and can purchase (and afterwards manage) their SaaS licenses. For this purpose I created (among others) the following REST endpoints:
// Lists all licenses which are linked to this user
r.Get("/users/{userID}/licenses", api.LicenseSvc.HandleGetLicenses())
// List details (such as purchase date, seat information, ...) for a given licenseID
r.Get("/users/{userID}/licenses/{licenseID}", api.LicenseSvc.HandleGetLicense())
// Creates a new license for the signed in user
r.Post("/users/{userID}/licenses", api.LicenseSvc.HandleCreateLicense())
// Each license has a limited number of seats. The license manager can free up seats to make room for others
r.Delete("/users/{userID}/licenses/{licenseID}/seats/{seatID}", api.LicenseSvc.HandleDeleteSeat())
The above endpoints are only supposed to be used in the webshop/license management panel. At the same time the same service has to serve endpoints for the SaaS products which actually use the license(s) a user has created/purchased before. This SaaS product needs different endpoints such as:
An endpoint to check at startup whether a given license is valid at all
An endpoint which also gets the license by ID (see above), but it should only return a subset of the license resource (e. g. it shouldn't return the date when the license was purchased)
My question
Due to the fact that I am building one REST API which is consumed by two different "audiences" (on the one hand the license manager/customer and on the other hand the SaaS software) I feel like I am running into conflicts.
The authentication of both audiences is different, both audiences want to access the same kind of resource (e. g. a license) but the resource "format" (no customer sensitive data for the SaaS requester) should be different depending on the audience.
Should this be reflected via different REST URLs or should I handle all that logic inside of my route handlers?
Should I even create two different services serving these different audiences? Like one API for the userpanel/license management and one for the SaaS products!?
REST is not very well prepared for these multi-client scenarios. i have seen many REST apis where certain attributes of resources will only be filled under certain circumstances where i find that perfectly fine. however i have also seen many examples of multiple use cases bunched into single resource models where the swagger documentation with its limiting structure terribly fails to communicate the purpose of each field.
so: as long as the use cases do not differ too much, i would try to keep the count of endpoints low.
tip: have a look at GraphQL, it is much better equipped for handling such cases with querying only for certain sets or even only asking for certain fields, putting the client in control. however using GraphQL as the primary interface is still somewhat exotic and comes with quite substantial initial cost compared to the plentiful REST infrastructure available. still worth it.
I use OSRM and would like to allow the user to select from different routing profiles (e.g. car / foot). The documentation states that I can define the profile during the extract and prepare process. Does this mean that I have to run seperate instances for each profile, each with its own .osrm file? (this is an issue because I run it for a dataset covering large areas (~100GB).
Yes, as of today OSRM doesn't support multiple profiles.
I have a single bluemix account for our company, serving multiple BUs, which each have their own organization in bluemix.
Each organization provides sites and services and we want all applications to be available on the same common domain name.
Can I re-use the same custom domain name in multiple organizations in bluemix? For each application I will assign a unique subdomain of course.
Or is this bad practice? Should I rather create a single organization and multiple spaces, one for each BU, instead? (Which would of course eliminate the problem - perhaps I have the answer!).
Yes, you should be able to do cf share-private-domain OTHER_ORG MY_CUSTOM_DOMAIN. This is a general feature of open-source Cloud Foundry, so it should work on Bluemix as well, but you should try it out to be certain.
Iam building a web portal which will be rented to customers on a hosted model (SAAS), where they will be using the entire portal features on their own domains with their own branding.
Now I don't want them to get the files of my web-portal, but still be able to use a custom branded portal.
One solution which someone suggested here was to host the branded version on my server and all it via an Iframe on the customer's domain. However I didn't like the idea very much.
One second approach which I researched and found was to host the portal on a fresh IP in my server and ask the customer to point his domain to that ip.
The webportal will be sold to lot of customers and they all will have separate User Interfaces and brandings, so this is needed.
Please suggest me what do you feel about my approach or if you guys have a better idea in mind please pour in your suggestions.
iFrames are evil.
With that said I would probably go with a subdomain approach. They add a subdomain like webportal.somecompany.com that points to you and have your webserver route them to the correct hosted instance of your application based on subdomain. That way their www.somecompany.com still goes to their website.
We're running a SAAS application that supports branding, and we do it by dynamically serving up CSS. If all of your customers have a unique domain name pointed at your server, you could select your CSS files by domain name: If a customer logs in at "http://portal.customer.com/login", you can have his HTML link to the file "/stylesheets/portal.customer.com.css", and so forth. Alternatively, you can create a subdomain for each of your customers, and point them all at your master server, using very similar code to pick the CSS.
This lets you have a single IP address for all customers (and only as many servers as you need to support all your customers behind that IP address), instead of one IP address / server per customer - should cut save on hosting costs!
(NOTE: I'm leaning toward the subdomain approach, the more I think about it. If you're using HTTPS, it would let you use a single "*.yourdomain.com" certificate, rather than trying to mess with separate certificates for each client domain.)
You don't need to run different IPs for different customers. HTTP 1.1 supports Host: like so
GET / HTTP/1.1
Host: example.com
This is how most shared hosts work. When a customer sets up their DNS records to point at your server/load balancer, the incoming requests will have your client's hostname in the headers. Whether you set up virtual hosts in say Apache or do it at the application level is up to you.
Please for your own sake don't do iframes. There's a lot of information on the web on architecture for multi tenant applications.
I made the experience that in such a scenario your customers will come up with any possible web UI requirement you can imagine. Therefore it is rather difficult to build a web UI framework that can accomodate to all the needs, in fact this would rather be a content management system.
Furthemore, for building the web UI, you may meet any combination of customer in-house development, 3rd party web agency or request to get it developed by yourself.
In such situations I made good experiences with offering the SaaS as actual web services allowing custom developed portals to run on top. With this, anybody can build the actual portal with the clients look and feel. You could offer development and hosting as an option.