First, we are discussing about new functions for this mechanism
The volatile group
When we think about such a distributed system, like Eunomia, we face a serious problem about authorization.
Because user identities are not always stored in the system's registry, it is difficult to enforce some access control to the users.
One of the solutions for this problem is to assign some fixed groups to the users.
A lot of systems use some group information for their access control, so by judging from where the user comes, we can assign some group to the user for authorization.
However, the authorizaion requirement changes dramatically according to the time or other conditions under such a ditributed system.
For example, when we provide a web meeting webservice in our system, we would like to make external users access to the web service only at certain times we invite them. In this scenario, the access control shold be done along with the time parameter.
Moreover, it is sometimes difficult to enforce such a group based authrization correctly even if a non-distributed system.
For example, some identity management software cannot modify user information immediately, because such software often does such a job as a batch.
Meanwhile some user registries and web applications have their authorization cashe for their performance improvements, so if we change such group information in the user registry, such modification does not always affect immediately.
To fit such a dynamic authorization requirement and solve such a consideration, we introduce a new authorization function, the volatile access group.
In this function, we define some rules for users that which groups should be assined after the authentication and when the user should be deleted from the groups. Because the group information is stored along with the users' authentication information on the system's memory area, the group information will be deleted from the authentication information immediately as soon as the rules meet.
We assume a lot of rules for this function.
For example;
- How long the user is assined in the group.
- When the user will be deleted from the group.
- How many times the user can access the web services before the user will be deleted from the group.
However, because this function is now just an optional one and under examining for improvement, we have not define the exact rules and data format on the system's memory yet.
The attribute names exchange function
Other protocols, SAML and OpenID, provide an mechanism for attributes exchange , but these mechanisms have some considerations.
1: The exchangeable attributes are only the attributes in the user registry of authentication server .
2: Because they use only a timestamp as a security related value in attribute exchange messages , it is vulnerable to replay attacks.
3: Before attributes are exchanged, they have to adjust the attributes names between services in case they use different names in the system.
This idea provides 3 mechanisms like below.
1: Allowing the attributes in the user registries of service serves to be exchangeable
2: Preventing replay attacks by inserting nonce data in the attribute exchange messages and validating the values
3: Allowing end users to map their attributes among services so that the attribute names adjustment is not needed before the attributes exchange
We describe the main behavior this mechanism with a protocol flow below .
In this flow, we focus on only an attributes exchange between service servers , however; when we think of the attributes exchange between an authentication server and a service server , there is no big differences because some messages are just omitted in such a case .
*Premise
A client user uses two web services (service A and B) with a web browser.
The user is already authenticated by an authenticate server for these services .
We will explain how the attributes in the service B is sent to the service A which the user is using .
*Message flow
1: The client user requests the attributes in the service B to the service A . (for example, the user asks the service A to use the email address in the service B )
2: The service A makes a redirect message (browser post redirect message) towards the service B, and sends it to the user.
3: The message is automatically sent from the end user to the service B .
4: An authentication process happens if the user is not authenticated in the service B .
5: The service B receives the message and sent an exchangeable attributes list to the user .
6: The user requests some attributes according to the list . Fist, this message is send to the authentication server .
7: The authentication server sighs the request message and return it to the end user .
8: The user send the sighed message to the service B .
9: The service B return the attributes to the user .
10: The user send the attributes to the service A .
In this message flow from 6 to 10, these message may send automatically by browser post functions like message flow from 1 to 3.
In this flow, the end user have to choose attributes which is required .
We realize a further function, the user can make a mapping table for attributes names among the service A and service B, by extending the previous message flow .
(In this scenario, the user won't need create the mapping rule again , if the rule is stored in the services . However, we don't define whether the mapping table is indefinitely stored or not in this idea .)
The new message flow extended by the attributes mapping function is below .
1: The client user requests the attributes in service B to service A .
2: The service A makes a redirect message (browser post redirect message) towards service B, and sends it to the user.
3': When the user request the exchangeable attributes list , the service B checks weather it has the mapping rule or not. If it does not have the list, it send a message to confirm which attributes in the service B are correspond to the requested attributes. If it has the list, this step is automatically skipped and the next process (from 6 to 8 in the previous flow) runs.
4': The service B send attributes to the user .
5': The user send the attributes to the service A .
We haven't decide these message formats yet, because we are now under the review of new message formats of Eunomia. Along with the new formats, we are going to adopt appropriate formats for this function.
----------------------------------------------------------------------
Second, we recieved valuable emails and are discussing about them.
Why don't you use email addresses for the identifiers?
I acknowledge the e-mail addresses are better information to identify users because the information will not be duplicated.
However, we should be careful when we use an e-mail address for authentication, because we must not authenticate the user until we can confirm the email address belongs to the user.
If we don't check the possession, the end user would use other user's email address deliberately, so we should not use email addresses of other site for local authentication.
We can affirm them easily, if we provide web based email addresses for users and require them to login with email addresses and passwords. But how many web services provide web based e-mail addresses for end users for this purpose? I believe that only gigantic service providers can provide them.
In most cases, web services do not provide e-mail addresses to users, and I think it is better to provide a simple and light way of sign-on which needs not to be premised on the huge service providers.
In my opinion, a simple text data like 'realm' is a good solution.
How to prevent replay attacks?
I implemented a timeout function to prevent a replay attack in this version.
In addition to the function, the latest message formats for a new version of which I am thinking are these two patterns.
*The first message format:
Whenever an authentication process runs, the requester server creates a session key for message encryption and retains the key info together with session id.
The session key info will be deleted after the authentication to prevent a replay attack.
The session key is valuable, because the requester server can confirm the response message must be sent by the responder, and we can verify the server decrypt the message should be the intended server because the session key is encrypted with the responder's key in the request message.
But this format is vulnerable against DOS attacks, because this format requires the requester to preserve the session information for a long time.
*The second message format:
Whenever an authentication process runs, the requester server creates a nonce and put it in the request message. After the authentication, the responder server returns the nonce information in the response message, and the requester server retains the information along with the session id in the session store. The requester server will reject a request which contains same nonce value.
This format is more tolerant against DOS attacks than the previous one, and the requester server can confirm the response message must be sent by the responder, too. But we cannot verify the responder should be the intended server.
Eventually, I will design a new message format based on these formats.