Hello!  Regarding checks like bandwidth limits and session time limit, when authorizing through a REST API, I guess we can do these checks in the authorization phase via the REST API too and return an appropiate response accordingly, is this correct? Example: check the user exists, check password matches, check user has not exhausted their allocated daily bandwidth. If it's not correct, what's the current best practice in this case? Thank you for the help! Il Lunedì 24 Luglio 2017 15:48, Arran Cudbard-Bell <a.cudbardb@freeradius.org> ha scritto:

I've tried your suggestion and it worked!

Great!

I wanted to ask you: are there any publicly available examples of implementations using authorize, authenticate, accounting, postauth (and any other operation) with a REST API?

No, unfortunately not.  If you've got some specific scenarios I can add some examples to wiki.freeradius.org.

Another question: If we perform the username & password check in authorize, I suppose there's not much we will need to do in authenticate, correct?

For PAP (Plaintext auth) that's correct.  When you have more complex authentication mechanisms like EAP-PEAP, EAP-TTLS, MSCHAPv2, then the authentication flow is different.  For those methods, you generally need to retrieve the "known good" password via the REST interface, then call the appropriate module in authenticate to actually do something with it. Could you do this with pap too if you're interested to see how it works. authorize {     rest     pap } authenticate {     pap } Then your JSON would be: {     control:Cleartext-Password := "<users password>" } You can also return hashed passwords.  The attributes that hold them are in dictionary.freeradius.internal (https://github.com/FreeRADIUS/freeradius-server/blob/89380b053b3c85d7150cd12...) Search for -Password. Note: Only Cleartext-Password will work for all authentication mechanisms.

Thank you!

No problem. -Arran