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