Eunomia realizes a distributed authentication system in a simple way .
We often meet with some difficulties when we try to connect many distributed authentication systems for single sign-on or mutual authentication. For example,
- Managing representative authentication servers
- Avoiding duplications of user identities among systems
- Implementing flexibility of attribute exchange
To solve these problems, Eunomia introduces 3 new functions.
- Defines a "realm name" as a kind of surname for users in order to identify "where they come from"
- Lets all servers act as both an authentication server and a normal web server
- Has each server possess a permission list with exchangeable attributes and rules defining which
attributes are allowed to be returned to a request message
The next picture is a simple overview of Eunomia.
Next lists the advantages of Eunomia in comparison with other protocols such as SAML and OpenID.
- Protocols such as SAML and OpenID require representative authentication servers (ex. Idp of SAMPL and OP of OpenID). When these authentication servers go down or undergo a change in spec, we cannot use the web servers that use them to authenticate users. Whereas with Eunomia, because each web server is independent of each other, server outages do not affect other servers' operations.
- Eunomia has a more flexible attribute exchange function than SAML and OpenID. With Eunomia, each server has an exchangeable attribute list which allows pliable responses to request messages.
- SAML doesn't have a function to solve ID redundancy, because it mainly focuses on ID federation. Eunomia is designed to solve the duplication from the beginning.
- SAML has a complicated message format and encryption/sign mechanism. In comparison, Eunomia's message format and encryption mechanism is remarkably lightweight.
- OpenID requires an unique URL for each person during the authentication process. This process using URL information is rather complicated. The authentication flow of Eunomia is simple.
In addition to that, we introduce two functions as options to strengthn the above advantages.
- The volatile group: Most systems use group information for authorization, and they store such information in their user registries. Such systems tend to become complex because they use some identity management software to manage such group information. This function realises that some group information with rules are stored along with a user's authentication information not on the registry but only on the system's memory area. Eunomia uses the group information for authorization, and when the system's condition meets the rules, the group infromation are deleted immediately.
- The attribute names exchange function: Under some distributed systems, attributes names are not always same among the systems and it is often difficult for administrators to write mapping rule files to reconcile the differences. Moreover, most current protocols for single sign-on only provide a function to exchange users' attributes between an authentication server and a service server. It means when we want to exchange attributes between service servers , we cannot realize it with existing protocols.
This function offers a web based name mapping function for administrators (and users) to simplify the mapping operations and a mechanism to exchange attribute values among serivce servers.
Because these functions are options and now under review, the details of these functions are written in the "Meeting Room" page.