Glewlwyd 2.0 roadmap

[babelouest]

I'm thinking about improvement that will be useful for Glewlwyd in the next release.

If you're willing to help, by making pull requests or helping me guiding Glewlwyd to a better future, feel free to do so!

If you have feature requests that you think may be useful or interesting, you can post comments on this issue.

The core will still be written in C with Ulfius/Hoel libraries and the goal will still be to provide an application to delegate authentication for http based services.

Since I had some feature requests for new authentication methods such as TOTP, and I guess other authentication methods may be required by others. I will implement a modular way to add new authentication back-end, with dynamic libraries.

Also, being able to provide other authentication process than OAuth2 would be a good idea, although I'm not sure how to handle that without designing a dangerous monster. So I won't make this a priority, but I'll think about it.

The front-end will be pimped too, but I don't want to reprogram all of it, so it will not change that much.

Finally, I realized that in the profile page, having just the ip address to identify a session or a refresh token is not enough, I will add the client id and the user agent too.

This is where I'm at on the design right now, hope the to do list will get bigger, but not too much....

[Radiergummi]

I'd volunteer to provide some time for the web interface and documentation. I've also got a little experience with 2FA, at least from the conceptual side.
Other than that, I'd have a small feature request too: the config file is getting pretty large. Many Linux tools therefore allow to include other files, often using an asterisk as a wildcard. I'm thinking of a structure like so:

etc/glewlwyd/
  glewlwyd.conf
  conf.d/
    ldap.conf
    jwt.conf

...etc. Then, in glewlwyd.conf on the last line, have a default include conf.d/*. That'd make things a little easier to handle and would allow users to structure things their way too. What do you think?

[babelouest]

Thanks @Radiergummi ,

Splitting config into separate fies is a good idea, there is the directive @include in libconfig and it looks straightforward, so it won't be too difficult to implement I guess.

The good part with using modules is also that each module will have its own configuration and it will be separated from the rest of the application. A module can have multiple instances, each one with its own configuration too. You can also save the configuration of a module in a file, a database, on a distant service, wherever you please, as long as the module implements it.

I've made similar approach in Angharad's sub projects, Benoic and Carleon, I will reuse the skills.

For the help on the web interface, what kind of help are you willing to provide?

[Radiergummi]

That sounds great! But just to clarify, if you say modules, do you mean configuration modules or actual application modules?

Considering the web interface, I'm a full time frontend developer, so I could overhaul the UI to make it fully responsive, fix the UX issues and create somewhat of an "identity" for Glewlwyd.
What do you think?

[babelouest]

I mean application modules. It's a kind dynamic library that must have a set of functions defined, it's a similar approach to interfaces in OOP for example. All the modules are loaded at startup by Glewlwyd, and are executed in sequence when a module call is requested.

For example, let's say you have the following modules enabled in Glewlwyd:

• ldap
• database

If a user is requesting a refresh_token via Glewlwyd with its login/password, then Glewlwyd will call the function authenticate_user in the ldap module, if not authenticated via ldap, Glewlwyd will call the function authenticate_user in the database module.

I accept your offer for the UI!
Glewlwyd was my first project on ReactJS, and I didn't know about react.js seeders, that's why it uses the library browser.js. Lately, I made another front-end react application for my other project: Taliesin, and there I used ReactJS/Redux and the official create-react-app to start the front-end. I thought about re-implementing Glewlwyd front-end using the create-react-app as well, very useful and much more simple for development. What do you think?
I'm using my projects to get new skills and to learn new technologies, so I'm familiar with front-end development but I suck at web design :p So your help on this part would be a bloody miracle! I totally agree with you helping me getting a "visual identification" :)

[Radiergummi]

Hey @babelouest, sorry for not having replied anything yet - I'm in the middle of moving to a new apartment and things have been pretty busy lately. I'm definitely going to come back to this though, I'm still working on integrating Glewlwyd into our application! :)

[babelouest]

The way I see it now, Glewlwyd 2.0 will be redisigned to host modules that will provide 2 kinds of services: authentication procedure modules and protocol module.
A module is a library (.so file) that must have a set of specific functions available to be called by Glewlwyd.

An authentication procedure module validates a user using its own requirements. I.E. login/password database, login/password LDAP, login/secret via TOTP, login/secret code sent via e-mail, etc.

• An authentication module can list users but not mandatory.
• To authenticate a user, Glewlwyd can use multiple authentication procedure modules.
• A module is linked to scopes (or access groups or authorization levels or whatever we'll name this concept).
• A scope can have multiple authentication procedure modules required, at least one.
• To grant access to a scope, the user must pass all authentication procedures attached to this scope.
• If multiple scopes are requested by a user, he/she must pass all authentication procedures combined of the scopes he/she has access to.

For example, a user request access to scopes g_profile and g_admin. The scope g_profile requires authentication procedure login/password, where the scope g_admin requires authentication procedure login/password and TOTP.
If the user is allowed for g_profile only, then only the login/password procedure will be required for he/she to get the authorization.
If he/she is allowed for g_profile and g_admin, then he/she will have the login/password and TOTP procedure to pass.

Authentication and protocol modules can be configured within Glewlwyd, to setup LDAP settings, database credentials, file paths, etc.

A protocol module will implement an authentication procedure. I.E. Oauth2, SAML, Oauth1, OpenID, etc.
The protocol module must follow this high-level process:
A user request access for the following scopes in the protocol standard, then the module will ask Glewlwyd if the user has access or not, then if the answer pleases the protocol module, it will send back an authorization scheme (token, certificate, assertion or whatever the protocol will name this concept).
If required, a protocol module can store data from an authentication process, like refresh tokens, but if possible, never in plain text, always as digests to avoid identity theft.

The front-end will be reworked to implement these changes and allow users and admins to administrate modules as well as the current fucntionalities.

[Radiergummi]

@babelouest that sounds great - I'd have another minor request though: Separate HTTP communication from module processing. Modules should return whatever fields they intend to respond with to the Glewlwyd main process, which will then send the actual response via HTTP to the client.
Reasoning is - let consumers choose their Content-Type to be application/json, application/x-www-form-urlencoded or whatever else possibly supported by Glewlwyd. Currently, you're bound to application/x-www-form-urlencoded which is slightly a hassle when working with JS in browsers.

Would that be achievable?

[babelouest]

The backend modules can be separated from the http interface.
In fact, they will have to be agnostic, the backend modules will have a set of functions available, but will exchange strings, numeric values or json objects using jansson library.

The front-end modules, the one that will interact with the user are difficult to be protocol agnostic, because you would have to add another layer on top to translate their languages into http, which would be overkill.

Concerning your request to replace the content type from application/x-www-form-urlencoded to application/json, it would be easy if you change it deirectly on the code, but the OAuth2 RFC specifies that application/x-www-form-urlencoded is the content-type by default, and all OAuth2 clients and interfaces use this content-type. So if you change it, it would not be OAuth2 standard: https://tools.ietf.org/html/rfc6749#appendix-B .

But the module architecture would allow anyone to change the behaviour more easily if it fits their needs.

[babelouest]

Glelwwyd 2.0 has now entered Beta version. You can download and install from the master branch.

[babelouest]

Thanks @aviezab !

So far the only medium used is this github project, there is no telegram group or other communication service.

You're welcome to contribute in any way you want: code, tests, documentation, feedbacks etc. <

Opening pull requests and new issues are welcome, I suggest to open one issue per feedback, rather than one issue with a bunch of different stuff in it. It's easier to follow.

[babelouest]

Glewlwyd 2.0 beta 3 is available!

OpenID Connect us available and webauthn scheme is fixed

[babelouest]

Glewlwyd 2.0 RC1 is out!

Ships TLS certificate authentication scheme is available, many improvements and many bugfixes

[babelouest]

Glewlwyd 2.0 RC2 has shipped

Fixes UI and backend bugs, improve TLS certificate authentication scheme by allowing Glewlwyd server to emit PKCS#12 certificates

https://github.com/babelouest/glewlwyd/releases/tag/v2.0.0-rc2

This should be that last Release Candidate before official 2.0.0 release

[babelouest]

Glewlwyd 2.0.0 is now ready!