On security, docker applications, risk-based authentication and more…


In an effort to help the community better understand the Gluu Server’s features and capabilities, from time to time we publish our answers to customer RFI’s on the blog (of course stripped of any sensitive and/or organization specific information).

If you have similar or additional questions, feel free to schedule a call with us to discuss. We hope this content is helpful, and thanks for reading!

Can you specify the defensive mechanisms for known attack vectors?

All the strategies with protecting web pages apply. The Gluu Server is normally put behind a hardened web server.

There are very few protected API’s on the Gluu Server:

  1. the OpenID and UMA token endpoints (requires client authentication);
  2. the Userinfo endpoint (requires OAuth access token);
  3. the client registration endpoint (for client update which requires a token).

Each Gluu form includes a signed value in a hidden field so you can’t post a login form that the Gluu Server did not render.

Remember that the Gluu Server is an OAuth Authorization Server. You need to consider all the security sections of OAuth documents: https://datatracker.ietf.org/wg/oauth/documents/ and the OpenID Connect specifications: https://openid.net/connect

The point is that using the Gluu Server is no guarantee that your applications have implemented security properly. You could write a terribly insecure application that uses the Gluu Server. See my slides on client development: http://gluu.co/client-slides

What is the Gluu Server topology best practice for 200k-600k users?

How many datacenters? How many of the users are active per day? Just as a rule of thumb, if you want redundancy, we recommend 4 VM’s for the web tier, and 4 servers for LDAP (a pair of each per data center).

Does Gluu support risk-based authentication? Are there any out-of-the-box templates which can be implemented?

Using the Gluu Server’s authentication interceptions scripts, you can call API’s which can tell you about the risk of a transaction. We like a product called Vericlouds, which tells you if the creds have been stolen and are available on the darkweb, or other IP address based risk scores. The Gluu Server supports multi-step authentication workflows. So during phase one, the context can be analyzed to determine if additional steps are required to mitigate additional risk. For example, a script may compare the user’s credentials to a database of credentials known to be compromised (Vericlouds provides such an API); if the credentials have been pwned, the Gluu Server can ask for additional authentication, and then present a form asking the user to set a new password.

Does Gluu support risk-based authentication based on behavioral algorithms?

Same as above. Our customers are using SaaS services for the behavioral analytics and device finger printing.

Can Gluu be integrated with security information and event management (SIEM) software? If yes, please describe how?

This is a question for the SIEM vendor. The Gluu Server produces standard logs, and we can write logs from the interception scripts in any format.

Can Gluu be integrated with Zabbix? If yes, please provide basic recommendations for what/how should be monitored on Gluu.

You should monitor all the normal stuff: CPU, Disk, Memory, Swapping and availability of the services via HTTP and checking the processes.

Are there any pitfalls, restrictions, or special recommendations for integrating Docker applications with the Gluu Server?

As long as the apps can talk to the Gluu Server on tcp/443, it doesn’t matter what the clients use as a deployment platform.

Can the Gluu Server be operated in Docker?

Yes, but not recommended now for production deployments.

What is the log format for the Gluu Server?

We use log4j for oxAuth and oxTrust. OpenLDAP logs are important too.

Do you have any guidance for how the mobile token can detect if the device has been jailbroken?

I think mobile client libraries would have to figure this out. Quick Google search turned up this one: https://github.com/scottyab/rootbeer

How is the mobile token protected on the device (e.g cryptographic camouflage)?

Gluu recommends the usage of AppAuth, which follows these recommendations. For more info, see the library homepages: Android and iOS.

Is there an SDK for mobile applications? Please describe the platform/version (Android,iOS).

See above regarding AppAuth.

Is there any possibility to share the “secret” between different applications on one mobile device?

Mobile devices don’t use client secrets. There is no way to protect a client secret on a mobile device, which is why PKCE is used. The app can always be decompiled.

Please describe how Gluu is protected against things like DDoS attacks?

It isn’t. DDoS protection happens at the network layer, or proxy layer, not the application layer. However, using the Gluu Server’s authentication interception scripts, you can call services that perform DDoS protection, like DOSArrest.

What is the best practice for distributing mobile tokens?

See answer above about the use of AppAuth. This is the only recommended strategy.

Does Gluu have an API for CASE and EVENT management?

No, the Gluu Server creates logs. In addition to standard log tools, we have an MQ based centralized log aggregation tool that sends logs to the database. But Gluu is a producer of logs for log analysis tools.

Does Gluu support managing the behavioral module from its GUI?

No, you must use interception scripts to define behavioral rules.

Does Gluu support token/session management from its GUI?

No. Gluu supports the OpenID Connect session management and front channel logout API’s. Session management events are initiated by the client, not by the server. In version 3.2 of the Gluu Server, we will support backchannel logout. However, the apps have to support this feature for it to work properly.

————————————-

We hope this is a helpful overview!

If you have any questions, or would like to discuss your own project, just schedule a call.