Proxy a RADIUS request with privacyidea

George_D · November 25, 2015, 6:58am

Hi Cornelius,

I was looking for a solution that could proxy a RADIUS authentication
request coming from a VPN user and display it on a web page.
In order for a human operator to be able to view the request and
deny/permit the VPN connection based on some information displayed on that
page (username, date, etc).
This would be a implementation of “4 eyes principle” different from the
one that exists in privacyidea.

Can privacyidea accommodate such request ?

Thanks a lot,
George

cornelinux · November 25, 2015, 10:06am

Hi George,

At the moment it does not do this out of the box.

But this could be very well/easily implemented with pending requests and
add a view to display these pending requests and let the “operator B”
approve these.

Need to look into pending HTTP requests and timeouts, but this can work.

But instead of using all the timeout stuff, we could also see if this
would work with challenge response. Today you can use challenge
response, i.e. you give an OTP PIN and then the server sends a challenge
and expects the response. This also works with the RADIUS protocol, but
the RADIUS Client (in this case the VPN) must support the RADIUS
Access-Challenge package.
Using Challenge Response, the operator could approve the Challenge and
this way we would not run into this timeout stuff!
So you should check if your VPN supports Access-Challenge.

Kind regards
CorneliusAm Mittwoch, den 25.11.2015, 01:37 -0800 schrieb George D.:

Hi,

You described the process correctly. You can set the time-out to
60-120 seconds or more.
Let’s say that “user A” calls in before and informs “operator B”
that he will initiate a VPN connection.
“Operator B” will open the screen and allow the connection.
If “user A” wants to connect to the VPN without informing “operator
B” then his request will be timed-out, which is why we need to confirm
manually (Allow) the connection.
Maybe “operator B” could also get an email with a link for
approval … just an idea.

So the idea is that no VPN connection will be established without
human intervention by “operator B”.
I’m afraid you can’t automate this as “operator B” needs to be part
of the process.

Hope this explains better the process.
Can privacyidea accommodate this scenario ?

Thanks,
George

On Wednesday, November 25, 2015 at 10:59:21 AM UTC+2, Cornelius Kölbel wrote:
Hello George,
    so let me see if I get this right: 
    
    A "user A" tries to login to a VPN. The VPN is connected to a
    RADIUS 
    server, so the VPN sends a RADIUS Access-Request to the RADIUS
    server. 
    Instead of processing the Access-Request the RADIUS server
    should put 
    this request on the Web Page, where an "operator B" may decide
    if the 
    user is allowed to login? 
    
    You realize that the Radius Access-Request will run into a
    timeout, 
    since the operator will not decide within seconds?! 
    
    So the "user A" will fail to login anyway. 
    
    What are you trying to achieve? 
    Don't you think it might make more sense to define rules? 
    If you are involving a human being for decision making, you
    will always 
    have a timeout problem. 
    
    Kind regards 
    Cornelius 
    
    
    Am Dienstag, den 24.11.2015, 22:58 -0800 schrieb George D.: 
    >  Hi Cornelius, 
    >   
    >  I was looking for a solution that could proxy a RADIUS
    authentication 
    > request coming from a VPN user and display it on a web
    page. 
    >  In order for a human operator to be able to view the
    request and 
    > deny/permit the VPN connection based on some information
    displayed on 
    > that page (username, date, etc). 
    >  This would be a implementation of "4 eyes principle"
    different from 
    > the one that exists in privacyidea.   
    > 
    >  Can privacyidea accommodate such request ? 
    >   
    >  Thanks a lot, 
    >  George 
    > 
    > -- 
    > You received this message because you are subscribed to the
    Google 
    > Groups "privacyidea" group. 
    > To unsubscribe from this group and stop receiving emails
    from it, send 
    > an email to privacyidea...@googlegroups.com. 
    > To post to this group, send email to
    priva...@googlegroups.com. 
    > To view this discussion on the web visit 
    >
    https://groups.google.com/d/msgid/privacyidea/41238f3d-9627-4b3c-84c5-3284ff0aea5d%40googlegroups.com. 
    > For more options, visit https://groups.google.com/d/optout. 
    
    -- 
    Cornelius Kölbel 
    corneliu...@netknights.it 
    +49 151 2960 1417 
    
    NetKnights GmbH 
    http://www.netknights.it 
    Landgraf-Karl-Str. 19, 34131 Kassel, Germany 
    Tel: +49 561 3166797, Fax: +49 561 3166798 
    
    Amtsgericht Kassel, HRB 16405 
    Geschäftsführer: Cornelius Kölbel 
–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/d4aa9d90-e88e-47f9-9103-136728ce0456%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

George_D · November 25, 2015, 9:37am

Hi,

You described the process correctly. You can set the time-out to 60-120
seconds or more.
Let’s say that “user A” calls in before and informs “operator B” that he
will initiate a VPN connection.
“Operator B” will open the screen and allow the connection.
If “user A” wants to connect to the VPN without informing “operator B”
then his request will be timed-out, which is why we need to confirm
manually (Allow) the connection.
Maybe “operator B” could also get an email with a link for approval …
just an idea.

So the idea is that no VPN connection will be established without human
intervention by “operator B”.
I’m afraid you can’t automate this as “operator B” needs to be part of
the process.

Hope this explains better the process.
Can privacyidea accommodate this scenario ?

Thanks,
GeorgeOn Wednesday, November 25, 2015 at 10:59:21 AM UTC+2, Cornelius Kölbel wrote:

Hello George,

so let me see if I get this right:

A “user A” tries to login to a VPN. The VPN is connected to a RADIUS
server, so the VPN sends a RADIUS Access-Request to the RADIUS server.
Instead of processing the Access-Request the RADIUS server should put
this request on the Web Page, where an “operator B” may decide if the
user is allowed to login?

You realize that the Radius Access-Request will run into a timeout,
since the operator will not decide within seconds?!

So the “user A” will fail to login anyway.

What are you trying to achieve?
Don’t you think it might make more sense to define rules?
If you are involving a human being for decision making, you will always
have a timeout problem.

Kind regards
Cornelius

Am Dienstag, den 24.11.2015, 22:58 -0800 schrieb George D.:

Hi Cornelius,

I was looking for a solution that could proxy a RADIUS authentication
request coming from a VPN user and display it on a web page.
In order for a human operator to be able to view the request and
deny/permit the VPN connection based on some information displayed on
that page (username, date, etc).
This would be a implementation of “4 eyes principle” different from
the one that exists in privacyidea.

Can privacyidea accommodate such request ?

Thanks a lot,
George

–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea...@googlegroups.com <javascript:>.
To post to this group, send email to priva...@googlegroups.com
<javascript:>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/privacyidea/41238f3d-9627-4b3c-84c5-3284ff0aea5d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
corneliu…@netknights.it <javascript:>
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

cornelinux · November 25, 2015, 12:21pm

Hi George,

it looks like anyConnect basically supports RADIUS chal resp.
But there also seem to be problems every now and then.
Nevertheless I would recommend to test this.

If you do not want to use a 2nd factor like OTP but only

username
password
operator interaction,

then you could do it like this:

user enters username
user enters 1st part of password.
A challenge is triggered
…and the user is presented with the second login
the operator needs to approve the challenge
The use may enter the 2nd part of the password.

If the user performs 6 before 5, he will not be able to login.

Kind regards
CorneliusAm Mittwoch, den 25.11.2015, 04:06 -0800 schrieb George D.:

Hi,

The VPN client used in this case is Cisco AnyConnect.
I’m sorry but I couldn’t find clear documentation regarding the
support for Access-Challenge in AnyConnect.
There are some references which makes me think it’s supported. Maybe
you know better.

Anyway at the moment for authentication I wanted to use
user&password.

Thanks,
George

On Wednesday, November 25, 2015 at 12:06:37 PM UTC+2, Cornelius Kölbel wrote:
Hi George,

    At the moment it does not do this out of the box. 
    
    But this could be very well/easily implemented with pending
    requests and 
    add a view to display these pending requests and let the
    "operator B" 
    approve these. 
    
    Need to look into pending HTTP requests and timeouts, but this
    can work. 
    
    But instead of using all the timeout stuff, we could also see
    if this 
    would work with challenge response. Today you can use
    challenge 
    response, i.e. you give an OTP PIN and then the server sends a
    challenge 
    and expects the response. This also works with the RADIUS
    protocol, but 
    the RADIUS Client (in this case the VPN) must support the
    RADIUS 
    Access-Challenge package. 
    Using Challenge Response, the operator could approve the
    Challenge and 
    this way we would not run into this timeout stuff! 
    So you should check if your VPN supports Access-Challenge. 
    
    Kind regards 
    Cornelius 
    
    
    Am Mittwoch, den 25.11.2015, 01:37 -0800 schrieb George D.: 
    >  Hi, 
    > 
    >   You described the process correctly. You can set the
    time-out to 
    > 60-120 seconds or more. 
    >   Let's say that "user A" calls in before and informs
    "operator B" 
    > that he will initiate a VPN connection. 
    >   "Operator B" will open the screen and allow the
    connection. 
    >   If "user A" wants to connect to the VPN without informing
    "operator 
    > B" then his request will be timed-out, which is why we need
    to confirm 
    > manually (Allow) the connection. 
    >   Maybe "operator B" could also get an email with a link
    for 
    > approval ... just an idea. 
    > 
    >   So the idea is that no VPN connection will be established
    without 
    > human intervention by "operator B". 
    >   I'm afraid you can't automate this as "operator B" needs
    to be part 
    > of the process. 
    >   
    >   Hope this explains better the process. 
    >   Can privacyidea accommodate this scenario ? 
    > 
    >  Thanks, 
    > George 
    >   
    > 
    > On Wednesday, November 25, 2015 at 10:59:21 AM UTC+2, Cornelius Kölbel  wrote: 
    >         Hello George, 
    >         
    >         so let me see if I get this right: 
    >         
    >         A "user A" tries to login to a VPN. The VPN is
    connected to a 
    >         RADIUS 
    >         server, so the VPN sends a RADIUS Access-Request to
    the RADIUS 
    >         server. 
    >         Instead of processing the Access-Request the RADIUS
    server 
    >         should put 
    >         this request on the Web Page, where an "operator B"
    may decide 
    >         if the 
    >         user is allowed to login? 
    >         
    >         You realize that the Radius Access-Request will run
    into a 
    >         timeout, 
    >         since the operator will not decide within seconds?! 
    >         
    >         So the "user A" will fail to login anyway. 
    >         
    >         What are you trying to achieve? 
    >         Don't you think it might make more sense to define
    rules? 
    >         If you are involving a human being for decision
    making, you 
    >         will always 
    >         have a timeout problem. 
    >         
    >         Kind regards 
    >         Cornelius 
    >         
    >         
    >         Am Dienstag, den 24.11.2015, 22:58 -0800 schrieb
    George D.: 
    >         >  Hi Cornelius, 
    >         >   
    >         >  I was looking for a solution that could proxy a
    RADIUS 
    >         authentication 
    >         > request coming from a VPN user and display it on a
    web 
    >         page. 
    >         >  In order for a human operator to be able to view
    the 
    >         request and 
    >         > deny/permit the VPN connection based on some
    information 
    >         displayed on 
    >         > that page (username, date, etc). 
    >         >  This would be a implementation of "4 eyes
    principle" 
    >         different from 
    >         > the one that exists in privacyidea.   
    >         > 
    >         >  Can privacyidea accommodate such request ? 
    >         >   
    >         >  Thanks a lot, 
    >         >  George 
    >         > 
    >         > -- 
    >         > You received this message because you are
    subscribed to the 
    >         Google 
    >         > Groups "privacyidea" group. 
    >         > To unsubscribe from this group and stop receiving
    emails 
    >         from it, send 
    >         > an email to privacyidea...@googlegroups.com. 
    >         > To post to this group, send email to 
    >         priva...@googlegroups.com. 
    >         > To view this discussion on the web visit 
    >         > 
    >
    https://groups.google.com/d/msgid/privacyidea/41238f3d-9627-4b3c-84c5-3284ff0aea5d%40googlegroups.com. 
    >         > For more options, visit
    https://groups.google.com/d/optout. 
    >         
    >         -- 
    >         Cornelius Kölbel 
    >         corneliu...@netknights.it 
    >         +49 151 2960 1417 
    >         
    >         NetKnights GmbH 
    >         http://www.netknights.it 
    >         Landgraf-Karl-Str. 19, 34131 Kassel, Germany 
    >         Tel: +49 561 3166797, Fax: +49 561 3166798 
    >         
    >         Amtsgericht Kassel, HRB 16405 
    >         Geschäftsführer: Cornelius Kölbel 
    >         
    >         
    > -- 
    > You received this message because you are subscribed to the
    Google 
    > Groups "privacyidea" group. 
    > To unsubscribe from this group and stop receiving emails
    from it, send 
    > an email to privacyidea...@googlegroups.com. 
    > To post to this group, send email to
    priva...@googlegroups.com. 
    > To view this discussion on the web visit 
    >
    https://groups.google.com/d/msgid/privacyidea/d4aa9d90-e88e-47f9-9103-136728ce0456%40googlegroups.com. 
    > For more options, visit https://groups.google.com/d/optout. 
    
    -- 
    Cornelius Kölbel 
    corneliu...@netknights.it 
    +49 151 2960 1417 
    
    NetKnights GmbH 
    http://www.netknights.it 
    Landgraf-Karl-Str. 19, 34131 Kassel, Germany 
    Tel: +49 561 3166797, Fax: +49 561 3166798 
    
    Amtsgericht Kassel, HRB 16405 
    Geschäftsführer: Cornelius Kölbel

–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/636a8380-0415-494f-88bb-8d89a33c26c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

cornelinux · November 25, 2015, 8:59am

Hello George,

so let me see if I get this right:

A “user A” tries to login to a VPN. The VPN is connected to a RADIUS
server, so the VPN sends a RADIUS Access-Request to the RADIUS server.
Instead of processing the Access-Request the RADIUS server should put
this request on the Web Page, where an “operator B” may decide if the
user is allowed to login?

You realize that the Radius Access-Request will run into a timeout,
since the operator will not decide within seconds?!

So the “user A” will fail to login anyway.

What are you trying to achieve?
Don’t you think it might make more sense to define rules?
If you are involving a human being for decision making, you will always
have a timeout problem.

Kind regards
CorneliusAm Dienstag, den 24.11.2015, 22:58 -0800 schrieb George D.:

Hi Cornelius,

I was looking for a solution that could proxy a RADIUS authentication
request coming from a VPN user and display it on a web page.
In order for a human operator to be able to view the request and
deny/permit the VPN connection based on some information displayed on
that page (username, date, etc).
This would be a implementation of “4 eyes principle” different from
the one that exists in privacyidea.

Can privacyidea accommodate such request ?

Thanks a lot,
George

–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/41238f3d-9627-4b3c-84c5-3284ff0aea5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

George_D · November 25, 2015, 12:06pm

Hi,

The VPN client used in this case is Cisco AnyConnect.
I’m sorry but I couldn’t find clear documentation regarding the support
for Access-Challenge in AnyConnect.
There are some references which makes me think it’s supported. Maybe you
know better.

Anyway at the moment for authentication I wanted to use user&password.

Thanks,
GeorgeOn Wednesday, November 25, 2015 at 12:06:37 PM UTC+2, Cornelius Kölbel wrote:

Hi George,

At the moment it does not do this out of the box.

But this could be very well/easily implemented with pending requests and
add a view to display these pending requests and let the “operator B”
approve these.

Need to look into pending HTTP requests and timeouts, but this can work.

But instead of using all the timeout stuff, we could also see if this
would work with challenge response. Today you can use challenge
response, i.e. you give an OTP PIN and then the server sends a challenge
and expects the response. This also works with the RADIUS protocol, but
the RADIUS Client (in this case the VPN) must support the RADIUS
Access-Challenge package.
Using Challenge Response, the operator could approve the Challenge and
this way we would not run into this timeout stuff!
So you should check if your VPN supports Access-Challenge.

Kind regards
Cornelius

Am Mittwoch, den 25.11.2015, 01:37 -0800 schrieb George D.:
Hi,

You described the process correctly. You can set the time-out to
60-120 seconds or more.
Let’s say that “user A” calls in before and informs “operator B”
that he will initiate a VPN connection.
“Operator B” will open the screen and allow the connection.
If “user A” wants to connect to the VPN without informing “operator
B” then his request will be timed-out, which is why we need to confirm
manually (Allow) the connection.
Maybe “operator B” could also get an email with a link for
approval … just an idea.

So the idea is that no VPN connection will be established without
human intervention by “operator B”.
I’m afraid you can’t automate this as “operator B” needs to be part
of the process.

Hope this explains better the process.
Can privacyidea accommodate this scenario ?

Thanks,
George

On Wednesday, November 25, 2015 at 10:59:21 AM UTC+2, Cornelius Kölbel wrote:
Hello George,
    so let me see if I get this right: 
    
    A "user A" tries to login to a VPN. The VPN is connected to a 
    RADIUS 
    server, so the VPN sends a RADIUS Access-Request to the RADIUS 
    server. 
    Instead of processing the Access-Request the RADIUS server 
    should put 
    this request on the Web Page, where an "operator B" may decide 
    if the 
    user is allowed to login? 
    
    You realize that the Radius Access-Request will run into a 
    timeout, 
    since the operator will not decide within seconds?! 
    
    So the "user A" will fail to login anyway. 
    
    What are you trying to achieve? 
    Don't you think it might make more sense to define rules? 
    If you are involving a human being for decision making, you 
    will always 
    have a timeout problem. 
    
    Kind regards 
    Cornelius 
    
    
    Am Dienstag, den 24.11.2015, 22:58 -0800 schrieb George D.: 
    >  Hi Cornelius, 
    >   
    >  I was looking for a solution that could proxy a RADIUS 
    authentication 
    > request coming from a VPN user and display it on a web 
    page. 
    >  In order for a human operator to be able to view the 
    request and 
    > deny/permit the VPN connection based on some information 
    displayed on 
    > that page (username, date, etc). 
    >  This would be a implementation of "4 eyes principle" 
    different from 
    > the one that exists in privacyidea.   
    > 
    >  Can privacyidea accommodate such request ? 
    >   
    >  Thanks a lot, 
    >  George 
    > 
    > -- 
    > You received this message because you are subscribed to the 
    Google 
    > Groups "privacyidea" group. 
    > To unsubscribe from this group and stop receiving emails 
    from it, send 
    > an email to privacyidea...@googlegroups.com. 
    > To post to this group, send email to 
    priva...@googlegroups.com. 
    > To view this discussion on the web visit 
    > 
https://groups.google.com/d/msgid/privacyidea/41238f3d-9627-4b3c-84c5-3284ff0aea5d%40googlegroups.com.
    > For more options, visit https://groups.google.com/d/optout. 
    
    -- 
    Cornelius Kölbel 
    corneliu...@netknights.it 
    +49 151 2960 1417 
    
    NetKnights GmbH 
    http://www.netknights.it 
    Landgraf-Karl-Str. 19, 34131 Kassel, Germany 
    Tel: +49 561 3166797, Fax: +49 561 3166798 
    
    Amtsgericht Kassel, HRB 16405 
    Geschäftsführer: Cornelius Kölbel 
–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea...@googlegroups.com <javascript:>.
To post to this group, send email to priva...@googlegroups.com
<javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/d4aa9d90-e88e-47f9-9103-136728ce0456%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
corneliu…@netknights.it <javascript:>
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel