Changes between Version 9 and Version 10 of doc/developer/TokenArchitecture

Show
Ignore:
Timestamp:
01/07/10 15:48:43 (9 years ago)
Author:
gbastien
Comment:

Added thoughts on how the future token architecture would work

Legend:

Unmodified
Added
Removed
Modified
  • doc/developer/TokenArchitecture

    v9 v10  
    5454 * expiration_date (MIN(NOW+token_max_connection_duration, NOW+token_max_total_duration-SUM(data transfer for all connections on this token), token_expiration_date)) 
    5555 * logout_reason Explains what caused the connection to be closed 
     56 
     57== How it would work, thoughts == 
     58 
     59Notes added by gbastien 2010/01/07 
     60 
     61Tell me if I'm wrong, but this is how I see the future token architecture concretely. 
     62 
     63 
     64With this new token architecture, the token itself would play a much more central part in the connection process and management than it does now. 
     65 
     66Right now, the authentication server uses the user as a central point in the connection.  A user is an entity, with a username and password, that is meant to represent a single physical person.  Yet this notion fails for models without users.  For instance a splash-only network has only one user, SPLASH_ONLY_USER and thus does not make a difference between each user (using different mac-address) and cannot profit from abuse control mechanisms, etc.  Moreover, for this, the code needs to add special case scenarios when current user is splash-only user. 
     67 
     68With Token2.0, the token would play the role the user now plays: represent the physical person connecting to the network, while the user will merely be an authentication scheme.   
     69 
     70Here is how the login process would work server-side 
     71 
     72 1. OPTIONAL Display the login page 
     73 1. OPTIONAL The user enter his credentials (user / pass, access code, NIP, password of the day) 
     74 1. Upon successful authentication 
     75    a. Get credentials for token purpose (for example, the user_id in a splash-only node, instead of the id of the SPLASH_ONLY_USER would be the mac address) 
     76    a. Delete connections with unused tokens for this user/mac 
     77    a. Does a reusable and valid token already exist for the current user? 
     78      i. YES, use this token 
     79      i. NO, Can the user get a new token? 
     80        1. YES, create a new token and use this one 
     81        1. NO, the user cannot connect, give him a reason and what to do (Abuse control violated, needs to buy new token, etc.) EXIT 
     82    a. Create a new connection for the token 
     83    a. Calculate the values for this connection according to network policies  
     84    a. Return the token to the gateway 
     85 
     86 
     87Full support for this would require: 
     88 
     89 - An easy way to personnalize the welcome page (login interface: user/pass, access code, choice of method, etc) May already be there 
     90 - Additions to admin interface of networks / nodes to manage the type of connections / tokens it allow.  We may want to have a mixed network of splash-only nodes, username / password and/or access code nodes, right?? 
     91 - Additions to admin interface to manage the tokens themselves.  Allow for different authentication modes to have different configuration value (bandwidth, expiration) per network / node? 
     92 - Changing the session object (and references to it) so that the references to the User object now refer to the token. 
     93 - Writing substantial code to support all this!! (implementation will be gradual of course)