AAA Architecture

1. AAA Architecture Use of a AAA Server Application Specification to Support Generic AAA Applications Across a Mesh of Interconnected AAA Servers With Policy Everywhere

2. Some Work Areas • Work authentication and accounting into sequences • Motivate the need for accounting policy • List message types • Develop requirements for data representation • Vision for a generic AAA Server • Vision for a mesh of interconnected AAA servers with policy everywhere • Develop auditing requirements • Develop a simulation model

3. Message Types(or Message Sections) • Authorization request/reply • Policy request/reply • Data request/reply • Event log indication/confirmation • Accounting indication/confirmation • Service (session) configuration indication/confirmation • Service (session) management indication/confirmation

4. Why a Generic AAA Server?(Sounds like an implementation problem) • Requirements for supporting generic applications may be different than for supporting a few hard-coded applications • Need a framework to support many applications with a minimum of application specific code

5. A Mesh of Interconnected AAA Servers with Policy Everywhere • Problem of object location • How does a server know that a relevant policy exists somewhere that should govern an authorization request? • When evaluating a policy, how does a server know how to retrieve the data attributes referenced by the policy?

6. Vision for a Generic AAA Server • An AAA server application specification would inform each specific AAA server how to handle all application-specific requests it will be called upon to handle. In many cases, no application-specific code will be required.

7. AAA Server Application Specification • Might look something like policy. • Would specify how to process every type of message that may be received from each entity role or specific entity • Would specify: • which attributes each message must/may contain • what messages to generate as a result of each received message • how to retrieve policies • which data attributes each policy may require evaluation against • where to go to retrieve data attributes

8. AAA Server Application Specification • Most of this can be accomplished by “configuration”. • In some cases, application-specific program modules (ASMs) may be required. • Example: to retrieve data attributes from a local legacy data store • However, ASMs should be compiled and linked independently of the AAA server itself. • The calling convention can be specified in the AAA server application specification.

9. Example of AAA Server Application Specification • We will explore an example loosely based on the distance learning application. • In this application there is a mesh of many servers fulfilling many roles. • Let’s examine a single server role -- a course registration server. • We’ll list the rules for how to process each type of AAA message that may be received from each server in the mesh.

10. How to Process an Authorization Request for Course Enrollment 1. Validate request • must contain certain attributes • request-id • service-type = course-enrollment • course-number • section-number • Student-id • may contain certain attributes • If invalid, return authorization reply with NAK 2. Send policy request to curriculum server • include course-number attribute

11. 3. Send authorization request to student account server • include student-id attribute 4. Evaluate configured policy • registration-status(course-number,section-number)=open • Retrieve registration-status(course-number,section-number) from local database. • If SQL or LDAP can be used, then perhaps instructions for how to retrieve this attribute can be configured with no need for application-specific code? • Evaluate and store result in pending authorization-request record (authreq)

12. How to Process a Policy Reply from the Curriculum Server 1. Validate reply • Must contain a course-enrollment-policy attribute • If reply contains error (example: invalid course number), handle it (record in authreq). 2. Parse policy (determine attributes needed to evaluate) • Validate policy • Policy may reference certain attributes: • course-status(course-number=pre-req) • If policy references unknown attributes, record error.

13. 3. If course-status attribute is needed to evaluate policy, then: • Send data request to Student Records AAA Server • Include • request for item 1 • student-id = 12345 • course-number = pre-req-1 • course-status(item-requested flag=1) • request for item 2 • student-id = 12345 • course-number = pre-req-2 • course-status(item-requested flag=1)

14. How to Process a Data Reply from the Student Records AAA Server 1. Validate reply • If it does not contain the requested attributes, then record error. 2. Get course-enrollment-policy from authreq. 3. Evaluate course-enrollment policy. • Retrieve policy from authreq. • Evaluate policy against data attributes from data reply message. • Record result in authreq.

15. How to Process Authorization Reply from Student Account Server 1. Validate reply • If error, record in authreq. 2. Record authorization result in authreq.

16. What to Do When All Outstanding Requests Have Been Answered 1. Retrieve authreq. 2. Check if any errors or NAKs were recorded. • If so, return authorization reply message with NAK. • Else return authorization reply message with ACK. • Return all reply attributes required to be returned. • Return any reply attributes that may be returned that are found in the authreq. 3. Update local registration database. • If this is by SQL or LDAP, can we specify how to update it in the AAA server application specification?

17. 4. Send service configuration indication message to Educator AAA Server. • Include all configuration attributes required to be returned. • These may include accounting configuration attributes. • Return any reply attributes that may be returned that are found in the authreq. • These will typically be included in the action clauses of various policies.

18. How to Process Service Configuration Confirmation from Educator 1. If error, then send service management message to requestor indicating that the authorized service cannot be provided. 2. If positive confirmation, then send service management message to requestor. Include attributes from service configuration confirmation.