Integration of authentication authorization and accounting...

Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing – Network resources access controlling

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

Reexamination Certificate

active

06298383

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of data communications networks. More particularly, this invention relates to a method and apparatus for unifying the operation of authentication, authorization and accounting services and proxy services in a data communications network.
2. The Background
ISPs (Internet Service Providers) and Telcos (telephone companies) typically offer wholesale internet access and retail internet access to their subscribers. Wholesale access is typically offered to subsidiary and specialized service providers, CLECs (Competitive Local Exchange Carriers), corporations, and Community of Interest (COI) providers. Naturally, the processing afforded customers of the wholesale variety differs from the processing afforded customers of the retail variety. Subscriber information for individual wholesale users is usually stored by those who lease data communications network access from the ISP or Telco. Hence, corporations, CLECs and COI providers do not normally share their user information with the wholesale providers. The ISP or Telco, however, typically also has its own retail subscribers whose user information is stored in its databases. Hence, the ISP or Telco must identify an incoming user as a wholesale user or a retail user and initiate different actions for an incoming user based upon this status.
See, for example,
FIG. 1
where a pure retail environment has a number of network access servers (NAS
1
, NAS
2
and NAS
3
) which provide data communications portals to the ISP's point of presence (PoP) on the data communications network. Each NAS is in communication with a conventional AAA (authentication, authorization and accounting) service maintained by the ISP. Incoming users connect to the NASes by dialing in over the telephone network or in another conventional manner.
Traditional wholesale ISPs and Roaming Service Providers offer network access through a technique called “Authentication proxying.” Proxying involves the transfer of the Authentication responsibility to the “owner” of the subscriber. Thus, if a corporation was to outsource its corporate intranet to an ISP, what it gives up is the maintenance of its dial-up servers (i.e., the NASes). It does not, however, normally want to give up the control or information of its employees. Hence, when a corporate user dials in to such an ISP's network access servers, the user essentially perceives that the user is dialing into a corporate facility when the user is actually dialing into the ISP's domain and then somehow gaining admittance to the corporation's intranet.
What really happens in that scenario is that the ISP determines that the user belongs to Corporation A(Corp
A
) by parsing either the fully qualified domain name (FQDN) supplied by the user, a DNIS ID, or some other mechanism. Having determined that the user trying to gain access belongs to Corp
A
, the ISP cannot really authenticate the user. As noted earlier, the user's record is still with the corporation. Hence, the ISP will “proxy” out the authentication transaction to the corporation. An AAA service within the corporation then identifies the user, verifies the password, and provisions the user. Then the AAA service notifies the ISP's proxy server that the user is acceptable and passes along provisioning details associated with the user (such as an IP address to use or a pool identification of an IP address pool from which an IP address needs to be allocated). The ISP then grants the user access to the network based upon the reply it gets back from the corporation. This technique is called “proxying.” This is shown in FIG.
2
.
To be able to do this, the ISP maintains minimal information on its proxy server
14
at its PoP. Information such as supported domain names, the IP address to which the transaction is to be sent, the port number to which the transaction is to be addressed, etc. are stored (see FIG.
3
).
For example, turning now to
FIG. 2
, user Joe@corpa.com dials in 40 to NAS
1
. A PPP (point to point protocol) session is raised between Joe and NAS,. An IPCP (internet protocol control protocol) session
42
is raised between NAS
1
, and proxy service
44
. In response NAS
1
sends a RADIUS (Remote Authentication Dial-In User Service protocol) access-request to proxy service
44
. Proxy service
44
then consults its local configuration database
16
. Proxy service
44
then makes a determination about where to send the access-request packet. Here it decides to send it to the AAA service
48
maintained in the Corp
A
domain
50
. The Corp
A
AAA
48
then consults its local database
52
and authenticates joe@corpa.com. Corp
A
AAA
48
then returns an access- accept packet to proxy service
44
which, in turn, sends an access-accept packet to NAS
1
completing the log-in of joe@corpa.com.
When the subscriber is granted access, or leaves the network, the accounting transactions will now have to be shared with the wholesale customers of the ISP/Telco. That is, the ISP/Telco will keep a record with which to bill or otherwise account to CorP
A
for services rendered and the record will also need to be sent to Corp
A
's AAA. Typically, the wholesale provider (e.g., the ISP) will use a roaming service product such as the Global Roaming Server™ (GRS), a product of Cisco Systems, Inc. of San Jose, Calif., to achieve this objective. In the retail case, the ISP/Telco will use a product like Cisco Secure™, a product of Cisco Systems, Inc., to act as an authentication, authorization and accounting (AAA) service to authenticate and authorize the user. This approach, however, poses some problems for the ISP/Telco.
The ISP/Telco needs to maintain two different sets of NASes as diagrammed in
FIG. 4
or it has to pipe all transactions through a GRS (proxy service) as diagrammed in
FIG. 5
which then has to make a decision as to whether the access-request transaction will be locally processed by the ISP/Telco (retail user) or remotely processed by the wholesale customer (wholesale user). The two products are independent products which maintain their own databases. They do not at present support a distributed architecture and hence will not scale by the number of PoPs users, etc. This poses the problem that multiple instantiations of the GRS will need to be configured and will not be able to properly load balance among the various NASes available at the PoP. Furthermore, should a GRS go down, the PoP may lose the services of the NASes in communication with the GRS that failed.
Accordingly, it would be desirable to provide a capability for allowing ISPs and Telcos to seamlessly offer wholesale and retail data communications network access, unify the disparate systems that specialize in these access control segments and scale both systems to simultaneously reside on a plurality of PoPs while behaving in a distributed manner within the data communications network.
SUMMARY OF THE INVENTION
A single database maintained centrally hosts both proxy service data and authentication, authorization and accounting (AAA) data. Data is then copied to storage used locally by each system when both systems are instantiated. Therefore the ISP/Telco need not maintain two different data bases. A protocol gateway (PGW) is used to determine if the incoming user is a wholesale or retail user. The PGW filters the domain portion of the access request to locate a remote AAA service. If one such service is found, the PGW routes the communication via the GRS to proxy it to the remote AAA service. The returned packet from the remote AAA service is then searched for an IP address to be assigned to the incoming user. If one is not found the PGW obtains a dynamically allocated IP address from a DHCP server (using an IP-Pool-ID if supplied in the returned packet from the remote AAA service). The same mechanism is used to forward accounting event packets from the NAS to the remote AAA service. The PGW may monitor more than one proxy service and/or AAA service

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Integration of authentication authorization and accounting... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Integration of authentication authorization and accounting..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Integration of authentication authorization and accounting... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2591287

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.