RE: OAUTH TOTP as 3rd prompt

2018-03-17 Thread Zappacosta, Rolando (Nokia - US/Overland Park)
Hi guys,

Same thing for me, as I couldn't make the openconnect embedded TOTP thing work 
I'm manually typing the TOTP code in.

BTW, to make all that automatic (as it was my need) you could do something like 
I did:
cert='certificate.pfx'
user='username'
passwd='password'
totpkey='TOTPkey'
url='RAS.URL'
#
{ echo $passwd;echo `oathtool --totp -b $totpkey`; }|openconnect 
--no-cert-check -c $cert -u $user $url

Actually I do some more things but you can get the idea.

Also, I'm speaking about a "generic" method for "receive that => send this" 
since some folks like to set MOTD, banners or that kinda things that may 
require some type of acknowledgement. For instance, I remember a case long time 
ago where the user was prompted to enter "yes" to accept some T access 
message.

HTH,
Rolando



From: Curtis Shimamoto [mailto:curtiskshimam...@gmail.com] 
Sent: Friday, March 16, 2018 8:29 PM
To: Zappacosta, Rolando (Nokia - US/Overland Park) 
<rolando.zappaco...@nokia.com>
Cc: openconnect-devel@lists.infradead.org; dw...@infradead.org
Subject: RE: OAUTH TOTP as 3rd prompt

Actually, though I ended up getting busy with work and giving up on trying to 
make it work, I ran into the same issue of it seemingly not recognizing the 
prompt. 

Once I disabled the alternative second factor authentication methods, leaving 
just TOTP, it stopped prompting for the 2FA choice at all simply moving 
directly to asking for the one time password. While this seemed like progress, 
I could not get it to ever do that which I expected.

I don't know if it is expecting a specific string in the prompt or should be 
identifying the 2FA by the order of prompts, since I didn't get that far. But 
it never managed to auto fill the oauth step no matter what I tried. Again, I 
gave up not long after getting the TOTP to be the third prompt, due to lack of 
time. So please don't think I have been stressing to make it work since my 
initial inquiry or anything.

Lastly, while unrelated to the issue, I'd like to take this opportunity to 
whole heartedly concur with Rolando that it seems the general consensus, at 
least amongst those privy to awareness of this project, is that openconnect 
undoubtedly rocks. Regardless of whether my TOTP can be auto filled or not, I 
am incredibly appreciative of this project. Thanks!
-- 
Curtis Shimamoto

On Mar 16, 2018 7:55 AM, "Zappacosta, Rolando (Nokia - US/Overland Park)" 
<mailto:rolando.zappaco...@nokia.com> wrote:
I'm facing this too, in my case openconnect doesn't detect the "Enter Your 
Microsoft verification code" OTP prompt from the RAS.

May I suggest to include a "--otp-msg-str" (OTP message string)? As an example 
for it, in my case I'd add this as a parameter
   --otp-msg-str='Enter Your Microsoft verification code'
to trigger the openconnect OTP code generation and sending.

Or it could be made even more generic. For instance, what about {;} tuples?

With it, one could not only do something like:
   --rcv-snd-str='Enter Your Microsoft verification code',`oathtool ...`
but also other things like:
   --rcv-snd-str='Please enter your passphrase: ','MyPassword'
or whatever else the RAS can come with in the future...

Last but not lease... openconnect rocks!!!  

Thank you guys!,
Rolando Zappacosta


> You're the second person this week to report that our current
> heuristics aren't doing the right thing for them. Quite feasibly the
> second for whom Cisco's native integration with things like the RSA
> Softoken API aren't likely to work either?
>
> If there *is* a "correct" way to determine which form field gets the
> OTP, I cannot imagine what it is.
>
> I think we want a --otp-form-field argument to allow people to
> override it.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel


RE: OAUTH TOTP as 3rd prompt

2018-03-16 Thread Zappacosta, Rolando (Nokia - US/Overland Park)
I'm facing this too, in my case openconnect doesn't detect the "Enter Your 
Microsoft verification code" OTP prompt from the RAS.

May I suggest to include a "--otp-msg-str" (OTP message string)? As an example 
for it, in my case I'd add this as a parameter
   --otp-msg-str='Enter Your Microsoft verification code'
to trigger the openconnect OTP code generation and sending.

Or it could be made even more generic. For instance, what about {;} tuples?

With it, one could not only do something like:
   --rcv-snd-str='Enter Your Microsoft verification code',`oathtool ...`
but also other things like:
   --rcv-snd-str='Please enter your passphrase: ','MyPassword'
or whatever else the RAS can come with in the future...

Last but not lease... openconnect rocks!!!  

Thank you guys!,
Rolando Zappacosta


> You're the second person this week to report that our current 
> heuristics aren't doing the right thing for them. Quite feasibly the 
> second for whom Cisco's native integration with things like the RSA 
> Softoken API aren't likely to work either?
>
> If there *is* a "correct" way to determine which form field gets the 
> OTP, I cannot imagine what it is.
>
> I think we want a --otp-form-field argument to allow people to 
> override it.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel


Re: OAUTH TOTP as 3rd prompt

2018-02-01 Thread David Woodhouse
On Wed, 2018-01-31 at 23:12 -0800, Curtis Shimamoto wrote:
> 
> "This behaviour is empirically determined by the requirements of the
> servers that we have tested with; if you find a configuration in which
> it is not appropriate, please let us know."
> 
> So in an effort to provide you all with an additional data point, and
> the possibility of helping others in asking about my own problem, I'm
> reporting this scenario as you've requested.

You're the second person this week to report that our current
heuristics aren't doing the right thing for them. Quite feasibly the
second for whom Cisco's native integration with things like the RSA
Softoken API aren't likely to work either?

If there *is* a "correct" way to determine which form field gets the
OTP, I cannot imagine what it is.

I think we want a --otp-form-field argument to allow people to override
it. 

smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel