Synopse

To content | To menu | To search

Tag - security

Entries feed

2014, Tuesday November 18

HTTP remote access for SynDB SQL execution

For mORMot, we developed a fully feature direct access layer to any RDBMS, implemented in the SynDB.pas unit.

You can use those SynDB classes to execute any SQL statement, without any link to the framework ORM.
At reading, the resulting performance is much higher than using the standard TDataSet component, which is in fact a true performance bottleneck.
It has genuine features, like column access via late-binding, an innovative ISQLDBRows interface, and ability to directly access the low-level binary buffers of the database clients.

We just added a nice feature to those classes: the ability to access remotely, via plain HTTP, to any SynDB supported database!

Continue reading...

2014, Saturday August 16

Will WebSocket replace HTTP? Does it scale?

You certainly noticed that WebSocket is the current trendy flavor for any modern web framework.
But does it scale? Would it replace HTTP/REST?
There is a feature request ticket about them for mORMot, so here are some thoughts - matter of debate, of course!
I started all this by answering a StackOverflow question, in which the actual answers were not accurate enough, to my opinion.

From my point of view, Websocket - as a protocol - is some kind of monster.

You start a HTTP stateless connection, then switch to WebSocket mode which releases the TCP/IP dual-direction layer, then you may switch later on back to HTTP...
It reminds me some kind of monstrosity, just like encapsulating everything over HTTP, using XML messages... Just to bypass the security barriers... Just breaking the OSI layered model...
It reminds me the fact that our mobile phone data providers do not use broadcasting for streaming audio and video, but regular Internet HTTP servers, so the mobile phone data bandwidth is just wasted when a sport event occurs: every single smart phone has its own connection to the server, and the same video is transmitted in parallel, saturating the single communication channel... Smart phones are not so smart, aren't they?

WebSocket sounds like a clever way to circumvent a limitation...
But why not use a dedicated layer?
I hope HTTP 2.0 would allow pushing information from the server, as part of the standard... and in one decade, we probably will see WebSocket as a deprecated technology.
You have been warned. Do not invest too much in WebSockets..

OK. Back to our existential questions...
First of all, does the WebSocket protocol scale?
Today, any modern single server is able to server millions of clients at once.
Its HTTP server software has just to be is Event-Driven (IOCP) oriented (we are not in the old Apache's one connection = one thread/process equation any more).
Even the HTTP server built in Windows (http.sys - which is used in mORMot) is IOCP oriented and very efficient (running in kernel mode).
From this point of view, there won't be a lot of difference at scaling between WebSocket and a regular HTTP connection. One TCP/IP connection uses a little resource (much less than a thread), and modern OS are optimized for handling a lot of concurrent connections: WebSocket and HTTP are just OSI 7 application layer protocols, inheriting from this TCP/IP specifications.

But, from experiment, I've seen two main problems with WebSocket:

  1. It does not support CDN;
  2. It has potential security issues.

Continue reading...

2014, Sunday January 5

AES encryption over HTTP

In addition to regular HTTPS flow encryption, which is not easy to setup due to the needed certificates, mORMot proposes a proprietary encryption scheme. It is based on SHA-256 and AES-256/CTR algorithms, so is known to be secure.

You do not need to setup anything on the server or the client configuration, just run the TSQLHttpClient and TSQLHttpServer classes with the corresponding parameters.

Continue reading...

2013, Wednesday September 4

HTTPS communication in mORMot

In mORMot, the http.sys kernel mode server can be defined to serve HTTPS secure content.

Yes, mORMots do like sophistication:

When the aUseSSL boolean parameter is set for TSQLHttpServer.Create() constructor, the SSL layer will be enabled within http.sys.
Note that useHttpSocket kind of server does not offer SSL encryption yet.

We will now define the steps needed to set up a HTTPS server in mORMot.

Continue reading...

2013, Wednesday June 19

SynPDF now implements 40 bit and 128 bit security

The trunk version of our Open Source SynPdf library now features encryption using 40 bit or 128 bit key size.

This is a long awaiting feature, and sounds working just fine from my tests.
Speed has been optimized (as usual with our libraries), as a consequence encrypting the content will only be slightly slower.

Continue reading...

2013, Friday June 7

Authentication and Authorization

Our mORMot framework tries to implement security via:
- Process safety;
- Authentication;
- Authorization.

Process safety is implemented at every n-Tier level:
- Atomicity of the SQLite3 database core;
- RESTful architecture to avoid most synchronization issues;
- ORM associated to the Object pascal strong type syntax;
- Extended test coverage of the framework core.

Authentication allows user identification:
- Build-in optional authentication mechanism, implementing both per-user sessions and individual REST Query Authentication;
- Authentication groups are used for proper authorization;
- Several authentication schemes, from very secure SHA-256 based challenging to weak but simple authentication;
- Class-based architecture, allowing custom extension.

Authorization of a given process is based on the group policy, after proper authentication:
- Per-table access right functionalities built-in at lowest level of the framework;
- Per-method execution policy for interface-based services;
- General high-level security attributes, for SQL or Service remote execution.

We will now give general information about both authentication and authorization in the framework.

In particular, authentication is now implemented via a set of classes.

Continue reading...

2013, Sunday January 27

Video about mORMot authentication

A new mORMot user notified on our forum that he just made a short video, about authentication and security with our framework, from the perspective of an AJAX Client.
Many thanks for sharing your experiences!

This video illustrate how RESTful authentication is implemented by mORMot.
It compares also with the unsecured scheme used with DataSnap - pretty informative.

Click here to watch the 5 minutes video.

Each time you are logged, a light session is created on the server, and is the root of all mORMot advanced security attributes.
Also a big difference with the heavy implementation of DataSnap session handling.

Note that the 1.18 upcoming revision feature Windows Authentication, i.e. automatic log with your Windows credentials.
With it, it is not even necessary to enter/remember/manage your login/password pair: mORMot is able to use your Windows domain security to let you connected.

Feedback is welcome on our forum.

2013, Saturday January 5

Domain-Driven-Design and mORMot

Implementing Domain-Driven-Design (DDD) is one goal of our mORMot framework.

We already presented this particular n-Tier architecture.

It is now time to enter deeper into the material, provide some definition and reference.
You can also search the web for reference, or look at the official web site.
A general presentation of the corresponding concepts, in the .NET world, was used as reference of this blog entry.

Stay tuned, and ride the mORMot!

Continue reading...

2012, Tuesday November 20

Authentication in mORMot using Windows credentials

By default, the hash of the user password is stored safely on the server side. This may be an issue for corporate applications, since a new user name / password pair is to be defined by each client, which may be annoying.

Since revision 1.18 of the framework, mORMot is able to use Windows Authentication to identify any user. That is, the user does not need to enter any name nor password, but her/his Windows credentials, as entered at Windows session startup, will be used.

Thanks a lot Chaa for making public your code proposal!
Open Source is so great sometimes!
Keep the good work!

Continue reading...

2012, Monday September 3

Client-Server allowed back to XE3 pro

The attempt to restrict the XE3 professional license did evolve into an amazing discussion in Embarcadero forums, and Delphi-related blogs.

David I announced the (reverted) EULA for Delphi Pro. Remote database access is again possible, with terms similar to Delphi Xe2.
You can check the Software License and Support Terms (EULA) for RAD Studio XE3 products.

This is good news, but also the opportunity to check the definitive terms.

In short, with the XE3 pro license, you have a deployment restrictive clause:

  • You can use DBExpress components and units only locally;
  • You can use DataSnap features only locally (it means that you can prototype using DataSnap, but are not allowed to deploy or redistribute DataSnap).

If you want to use those two features on Client-Server, you would need to buy a Client/Server Pack license:

If licensee has purchased a Client/Server Pack, the Licensee of RAD Studio, Delphi, or C++Builder XE3 Professional Edition (“Product”) may deploy that portion of the Product identified as "dbExpress" and dbExpress enterprise database drivers, in executable form only, to enable client server database access. Embarcadero may deliver the Product identified as “Enterprise,” however Licensee is licensed to use only the “Professional” edition features plus "dbExpress" and the Enterprise dbExpress database drivers in a client/server configuration. Licensee may evaluate the n-Tier DataSnap functionality included in the Enterprise Product delivered, but may not deploy or redistribute DataSnap.

This is now a real opportunity for our Open Source mORMot framework.
With a XE3 pro license, and even with a XE3 starter license, you are able, via our free units and classes:

That is, everything you need to build from a small Client-Server or stand-alone application up to the most scalable Domain-Driven design.

Nice, isn't it?

2012, Thursday July 12

One ORM to rule them all

If you discovered the mORMot framework, you may have found out that its implementation may sound restricted, in comparison to other ORMs, due to its design. It would be easy to answer that "it is not a bug, it is a feature", but I suspect it is worth a dedicated article.

Some common (and founded) criticisms are the following (quoting from our forum - see e.g. this question):
- "One of the things I don't like so much about your approach to the ORM is the mis-use of existing Delphi constructs like "index n" attribute for the maximum length of a string-property. Other ORMs solve this i.e. with official Class-attributes";
- "You have to inherit from TSQLRecord, and can't persist any plain class";
- "There is no way to easily map an existing complex database".

I understand very well those concerns.
Our mORMot framework is not meant to fit any purpose, but it is worth understanding why it has been implemented as such, and why it may be quite unique within the family of ORMs - which almost all are following the Hibernate way of doing.

Continue reading...

2012, Monday May 28

Synopse mORMot Framework 1.16

Our Open Source mORMot framework is now available in revision 1.16.

The main new features are the following:

Thanks to its features, mORMot is now able to provide a stand-alone Domain-Driven Design framework for Delphi.

Quite a long and nice road for a little mORMot, and more to come!

Continue reading...

2012, Friday April 20

WCF, mORMot and Event Sourcing

Our latest mORMot feature is interface-based service implementation.

How does it compare with the reference of SOA implementation (at least in the Windows world) - aka WCF?

"Comparaison n'est pas raison", as we use to say in France.
But we will also speak about Event Sourcing, and why it is now on our official road map.
Comparing our implementation with WCF is the opportunity to make our framework always better.

Continue reading...

2012, Wednesday March 28

Return custom content from an interface-based service

As stated by this previous article, the default answer format is a valid JSON object.

In some cases, it may be useful to have a service operation (i.e. an interface method) returning any content, e.g. some plain TEXT, HTML or binary data (like a picture).

Continue reading...

2012, Wednesday March 7

Interface based services - sample code

In addition to the other related blog articles, you can find in the "SQLite3/Samples/14 - Interface based services" folder of the supplied source code distribution, a dedicated sample about this feature.

Purpose of this code is to show how to create a client-server service, using interfaces, over named pipe communication.

Continue reading...

Interface based services - Implementation details

You will find out in SQLite3Commons.pas all classes implementing this interface communication.

There are two levels of implementation:
- A services catalog, available in TSQLRest.Services property, declared as TServiceContainer (with two inherited versions, for each side);
- A service factory for each interface, declared as TServiceFactory (also with two inherited versions, for each side).

In fact, TServiceFactory.Create constructor will retrieve all needed RTTI information of the given interface, i.e. GUID, name and all methods (with their arguments). It will compute the low-level stack memory layout needed at execution. And the corresponding "contract" will be computed, to validate that both client and server expect the exact same interface.

On the server side, TServiceFactoryServer.ExecuteMethod method (and then a nested TServiceMethod.InternalExecute call) is used to prepare a valid call to the implementation class code from a remote JSON request.

On the client side, a TInterfacedObjectFake class will be created, and will emulate a regular Delphi interface call using some on-the-fly asm code generated in the TServiceFactoryClient.Create constructor.

Continue reading...

Interface based services - Using services on the Client or Server sides

Once the service is registered on the server side, it is very easy to use it in your code.

In a complex Service Oriented Architecture, it is pretty common to have services calling each other. Code re-usability is a key here. So you'll have to consume services on the server side. According to the SOLID design principles, you'd better rely on abstraction in your code, i.e. not call the service implementation, but the service abstract interface.

You can use the following method of your TSQLRest.Services instance (note that this method is available on both client and server sides, so is the right access point to all services):

 function TServiceFactory.Get(out Obj): Boolean;

Continue reading...

Interface based services - Server side

In order to have an operating service, you'll need to implement a Delphi class which matches the expected interface.

Continue reading...

Interface based services - defining a data contract

In a Service Oriented Architecture, services tend to create a huge list of operations.
In order to facilitate implementation and maintenance, operations shall be grouped within common services.

The data contract is to be defined as a plain Delphi interface type.
In fact, the sample type as stated in a previous blog article can be used directly:

type
  ICalculator = interface(IInvokable)
    ['{9A60C8ED-CEB2-4E09-87D4-4A16F496E5FE}']
    /// add two signed 32 bit integers
    function Add(n1,n2: integer): integer;
  end;

This ICalculator.Add method will define one "Add" operation, under the "ICalculator" service (which will be named internally 'Calculator' by convention).
This operation will expect two numbers as input, and then return the sum of those numbers.

Continue reading...

Interface based services

The Client-Server services via methods implementation (our DataSnap-like feature) gives full access to the lowest-level of the mORMot's core, so it has some advantages:
- It can be tuned to fit any purpose (such as retrieving or returning some HTML or binary data, or modifying the HTTP headers on the fly);
- It is integrated into the RESTful URI model, so it can be related to any table/class of our ORM framework (like DataAsHex service above), or it can handle any remote query (e.g. any AJAX or SOAP requests);
- It has a very low performance overhead, so can be used to reduce server workload for some common tasks.

But this implementation pattern has some drawbacks:
- Most content marshaling is to be done by hand, so may introduce implementation issues;
- Client and server side code does not have the same implementation pattern, so you will have to code explicitly data marshaling twice, for both client and server;
- The services do not have any hierarchy, and are listed as a plain list, which is not very convenient;
- It is difficult to synchronize several service calls within a single context, e.g. when a workflow is to be handled during the application process (you have to code some kind of state machine on both sides);
- Security is handled globally for the user, or should be checked by hand in the implementation method (using the aParams.Context values).

You can get rid of those limitations with the interface-based service implementation of mORMot. For a detailed introduction and best practice guide to SOA, you can consult this "classic" article.

According to this document, all expected SOA features are now available in the current implementation of the mORMot framework (including service catalog aka "broker").

Continue reading...

- page 1 of 2