< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

RE: [reSIProcate] ServerAuthManager/UserAuthInfo (and a few otherthings)


> Upon receving a response, i don't have the user's password - only a
yay or
> nay, so can't provide A1 back in the UserAuthInfo.
> 
> I've worked around both of the above as a quick fix and changing
> ServerAuthManager::handle to virtual (which i'm guessing it probably
> should
> be anyway?), but it would make a lot more sense to abstract
> resip::ServerAuthManager to take in to account different
authentication
> models, such as the one i'm forced to live with (at least for the time
> being).  I'm also working on a seperate 3GPP IMS project which would
have
> simalar requirements in an S-CSCF element, but using diameter and a
> seperate
> response verification algorithm.
> 
> I also need to be able to return a secific error - i.e 408, 500 etc
> depending
> on the remote authentication service response.

[Scott] I'm not really familiar with RADIUS so I can't really comment
whether you are approaching this correctly.  But I do agree that
handle() in ServerAuthManager should be virtual.  Also - I think,
overriding ServerAuthManager is the correct way to add "custom"
authentication mechanisms.  I will commit this change.

>  * what are the general thoughts on api changes, when do they get
> commited,
> what sort of release schedule is there (i couldn't see anything on the
> wiki)

[Scott] There really isn't a release schedule yet.  The stack is still
relatively new - reflected by its 0.9 version.  I suspect once we get
into the 1.x+ versions these details will be worked out.

> As a (slightly) seperate issue - resip should return
401/WWW-Authenticate
> to a
> request not being proxied, but there doesn't seem to be any support
for
> that
> at the moment.  Any quick pointers on where to look to make these
changes?

[Scott] I'm not sure what you mean here.  Are you referring to the repro
proxy?

> Also, I need to add a seperate fd to be monitored before calling
> stack.process() for my radius responses.  I couldn't see any way that
this
> has been abstracted to make it easy - i'm currently adding to fddset
after
> stack.buildFdSet(fdset), then checking if it's readable before calling
> stack.process().  any thoughts/pointers on this (or am i maybe missing
> somehting?)

[Scott] This method seems like the way to go, to me!

Scott