Caching authentication credentials surely speeds up the SIP digest authentication process a little bit. At the same time, it introduces a state synchronization issue because the credential database's state may differ from the credential cache state. What happens if I change a password in the database? Does it trigger a cache update?
In my opinion, these issues together with added code complexity outweigh the slight speed improvements resulting from a credential cache. Performance measurements with mysql and ldap backend have shown that openser can handle a huge number of authenticated SIP requests (>300 cps on dual xeon) without caching of auth credentials. /Christian JB74 wrote: > Hello all, > > Thank you for your responses. > > Indeed, I was thinking about a caching mechanisms similar to the one used in > IMS, as Klaus described in the previous post. > > If I store in a memory structure the authentication credentials (i.e. user > and password) following some cache policy, I could use this structure to > check if the user exists and check his/her identity without having to > contact a remote database/radius server (where network latency typically is > a bottleneck). If the user credentials are not in the cache, then OpenSER > will contact the database/radius server to authenticate the user (normal > procedure). > > Maybe I am oversimplifying the problem. Could you help me to understand > better why this is not possible? > > Thanks, > JB > > > > Klaus Darilion-2 wrote: >> >> >> Iñaki Baz Castillo schrieb: >>> El Lunes, 18 de Febrero de 2008, Juha Heinanen escribió: >>>> Bogdan-Andrei Iancu writes: >>>> > Credential caching is not support - for any of the backends (radius >>>> or >>>> > sql). As far as I know, there are no plans for caching yet... Mainly >>>> > because the fetching the passwd from DB is combined in a single query >>>> > with caller profile fetching - see the "load_credentials" module >>>> param >>>> > in auth_db module. >>>> >>>> yes, when i radius authenticate a user, the reply contains lots of user >>>> attributes as reply items. these attributes can change any time and >>>> thus cannot be cached. >>> In fact I think that the only caching making sense would be directly in >>> the >>> final backend (DB, Radius, LDAP..). >> FYI: I think the original question refers to IMS, where the S-CSCF can >> retrieve pre-calculated nonces and responses from the diameter server to >> avoid diameter requests for each authentication. >> >> klaus >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.openser.org/cgi-bin/mailman/listinfo/users >> >> > _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
