bypassing authentication

esi · 2013-05-26 07:57:23

Hi!

I'm a total n00b with mORMot and still trying to figure out how things work, so please be patient with me ;-)

I'm trying to implement a rather simple REST server over HTTP(S), with no database access and no default authentication, but I do need session support (I just want to store a few session-specific values per session, as I could do in IntraWEB).

Now, since sessions require authentication, but the latest version of mORMot has Windows Authentication support, my idea was to let mORMot authenticate the user with SSPIAUTH specifying an empty user name. Of course, the next issue I'm hitting is that the Windows name needs to be pre-configured on the server to allow access and I'd like to avoid it. Is there any way to allow access to everyone somehow? I.e.: either with no configuration files/databases at all (preferably), or at least with a configuration file that has "*" or "ALL" or "EVERYONE" for a name?

The next thing is that I'm not going to use this server with a Delphi client, so
1) I need to document all URI's my server will expose for the users, who will then be able to implement the client in any language;
2) I would really like to drop this entire authentication process along with the root/Auth URI's, primarily to keep it short and simple, and
3) I'd like to keep it all in clear text as much as possible, to avoid requiring the users to use any hashing or encryption algorithms that may not be readily available in their language of choice.

I will need some authentication internally later on, but I will need to build it all myself, i.e.: I'll have additional methods exposed through REST for the users to provide their credentials. That's mostly because I need more than name/password values. But also because I will be authenticating the users against a third-party provider: I do not know what names/passwords may be valid there and cannot have a database of them pre-configured for this service in advance.

Incidentally, if the user can be authenticated transparently in the background via the Windows Authentication (SSPIAUTH), I will happily use their Windows User Names for logging and any kind of audit trail as may ne necessary.

So, to summarize:
1) I need to either disable and remove all and any authentication, including the need to go through root/Auth URI's, or
2) Use SSPIAUTH authentication, but somehow avoid using Auth URI's and also allow access to all and every connection.
plus additionally
3) I need to figure out the URI structures for all requests and so far I have not found any detailed reference about the URL structure. In fact, if there are any special internal URI's that can return such details, effectively making the server self-documenting, it would be even better.

Any pointers will be appreciated! Even if it turns out that I'm asking the wrong questions or even looking at this problem from a wrong point of view...

TIA, Alex.

esi · 2013-05-27 08:22:46

I'm basing all this around Sample 14. I have also noted that Sample 9 does not use any of the stuff that I worry about, but neither does it give me session support or automatic REST handling ;-(

ab · 2013-05-28 09:08:38

Seems related to http://synopse.info/fossil/tktview?name=8c8a2a880c

A new "no authentication" scheme is to be added.
I've added it to the list.

But for session handling, you will need at first to call once the Auth URI to retrieve the session ID.

Did you read http://blog.synopse.info/post/2011/05/2 … entication
about how authentication is implemented?

See also http://blog.synopse.info/post/2012/03/0 … on-details
about the current JSON layout for interface-based services.
Is it OK for you?

esi · 2013-05-29 02:46:47

Arnaud,

Many thanks! Yes, it's a lot to read, I'll need to digest it all ;-)

Indeed, my needs look very close to this request. I think this request has a much wider scope. I was really hoping to be able to plug-in my own authentication code somewhere immediately, like overriding TSQLRestServer.Auth method, or something. But, of course, there are always so many different ways to skin the proverbial cat ;-)

Yes, I saw the Auth implementation details. Again, it's clearly suitable for a DB. And it's very easy to use from a Pascal client. For me, I'll need to get more details than just the name/password pair, will need to then authenticate these details externally (and before I do, I won't know if they are valid) and finally make it all very simple and usable for implementation in any language, or indeed for simple GET requests from a browser, including clear documentation on my side.

That's if I do end up using this method of authentication. Because there are still other possible alternatives, i.e.: I could rely on Windows authentication, just as a simple way to obtain the user's Windows login name + start a session, but then I will want it to be more streamlined, with no nonces or hashes and I will want to always return success on any user name every time and then do my authentication separately as part of my REST implementation.

And thanks for the layout details, I did not see those. I'm not up to scratch with the REST ideology, so my first idea was to use GET for everything: what I need to do does not really translate into DB operations, so the distinction between GET/POST/... do not make direct sense to me. But under the same token, it would then make no difference to me if all my REST requests were POST's, only that I don't think they would still be directly accessible from a browser, which was what I was using to test my REST functions so far.

Ok, so to summarize: looks like I will need to wait for this enhancement, then. Right? I don't think anything like overriding TSQLRestServer.Auth with the current version is feasible (or simple). And then if these enhancements are not already under way, then I'll probably end up building up on Sample9 and just stick with the fast HTTP in mORMot. What do you think?

Thanks again, Alex.

ab · 2013-05-29 08:52:31

Sounds right.

I can implement this feature request in prority.
Does make sense.

esi · 2013-05-29 09:02:04

Thank you very much, that would be fantastic! What sort of timeframe do you expect to need for this change?

esi · 2013-06-04 13:57:16

Arnaud, do you think you would be in a position to do it over June, or is it looking bigger than that?

ab · 2013-06-04 15:09:04

I'm currently working on it.
I'll post some class-driven authentication process in mORMot.pas.

"No-authentication" will be the first added class, in addition to the two existing means: i.e. mORMot authentication and Windows SPPI authentication.
You can expect get it in a few days.
(I'm on hollidays, so a bit less efficient than usual)
(but since I'm in the mountains - French Pyrénées - I hear a lot of mORMots everywhere....)

esi · 2013-06-05 05:52:46

Thanks!

Say "Hi!" to all the mORMots up there for me, will you? ;-)

ab · 2013-06-06 20:30:47

Yesterday, I saw a lot of mORMots in the wild.
So nice!

Now they have a new friend, named TSQLRestServerAuthenticationNone.
Testing is included.
Documentation has been enhanced a lot (in the "Security" paragraph of the SAD pdf).

See http://blog.synopse.info/post/2013/06/0 … horization

So, for bypassing authentication, do not use
- TSQLRestServer.Create() with authentication=true but Server.RegisterAuthentication(TSQLRestServerAuthenticationNone)
- Client.SetUser() but TSQLRestServerAuthenticationNone.ClientSetUser()

Feedback is welcome!

esi · 2013-06-09 01:45:45

Thanks! I'll need to play with this for a while...

esi · 2013-06-09 01:59:28

Correction: I think it's not "RegisterAuthentication", but instead "AuthenticationRegister"...

esi · 2013-06-09 02:17:28

Getting access violations on the server on any attempt to call auth?UserName=xxx (whether with an existing user name or not). - I'm mocking around with Sample14ServerHttp project.

BTW, with this implementation, I still have to maintain a local DB/file with at least one user name in it, right? No way to ignore it / accept any name?

esi · 2013-06-09 03:10:04

And on a side topic, I've just tried Sample09 and it always processes all HTTP requests from the same single thread, which was not really what I expected. I.e.: I've added IntToStr(GetCurrentThreadID) to the end of html, then start a few dozen IE sessions to this URL all at once and they all show the same ID... I'll need to dig a lot more...

ab · 2013-06-10 07:23:37

esi wrote:

Getting access violations on the server on any attempt to call auth?UserName=xxx (whether with an existing user name or not). - I'm mocking around with Sample14ServerHttp project.

With weak authentication, you need to explicitly add TSQLAuthUser and TSQLAuthGroup to the model.
I've also added a new Project14ServerHttpWeak sample.

esi wrote:

And on a side topic, I've just tried Sample09 and it always processes all HTTP requests from the same single thread,

Indeed.
This low-level class IS a single thread, inheriting from TThread.

When you access directly this low-level class, you have to explicitly call the Clone() method to create other threads.
This is stated by the doc, BTW.

mpv · 2013-11-05 08:35:32

AB, in my implementation I rewrite fPublishedMethodsUnauthenticated analog using TBits. I think this more simple and faster compared to IntegerDynArray. In my analog of TSQLRestServer.URI instead of

      not IntegerScanExists(pointer(fPublishedMethodsUnauthenticated),
        fPublishedMethodsUnauthenticatedCount,URI.MethodIndex)) then begin

now

      not fPublishedMethodsUnauthenticated.Bits[URI.MethodIndex] then begin

May be you decide to do such modification in mORMot..

ab · 2013-11-05 12:29:48

Why not?

In fact, I've used another approach, i.e. maintaining an array of method information instead of using a TRawUTF8ListHashed.
It features a new TSQLRestServer.ServiceMethodRegisterPublishedMethods() method to allow multi-class method-based services (e.g. for implementing MVC model).
See http://synopse.info/fossil/info/dffe0d7462

mORMot Open Source

#1 2013-05-26 07:57:23

bypassing authentication

#2 2013-05-27 08:22:46

Re: bypassing authentication

#3 2013-05-28 09:08:38

Re: bypassing authentication

#4 2013-05-29 02:46:47

Re: bypassing authentication

#5 2013-05-29 08:52:31

Re: bypassing authentication

#6 2013-05-29 09:02:04

Re: bypassing authentication

#7 2013-06-04 13:57:16

Re: bypassing authentication

#8 2013-06-04 15:09:04

Re: bypassing authentication

#9 2013-06-05 05:52:46

Re: bypassing authentication

#10 2013-06-06 20:30:47

Re: bypassing authentication

#11 2013-06-09 01:45:45

Re: bypassing authentication

#12 2013-06-09 01:59:28

Re: bypassing authentication

#13 2013-06-09 02:17:28

Re: bypassing authentication

#14 2013-06-09 03:10:04

Re: bypassing authentication

#15 2013-06-10 07:23:37

Re: bypassing authentication

#16 2013-11-05 08:35:32

Re: bypassing authentication

#17 2013-11-05 12:29:48

Re: bypassing authentication

Board footer