Re: [Cosign-discuss] Conditional Factors

2013-01-22 Thread Mark Montague
On January 22, 2013 4:55 , Florian Mueller  wrote:
> Yes, I did configured the factor as secondary (-2) but the problem was 
> that I didn't know how to enable factors only for specific users 
> instead of services. In our environment the user should be able to 
> decide whether he wants to use Google Authenticator or not.
>
> But in the meantime I solved it by enabling the factor in all services 
> and query some database inside the factor which determines whether the 
> user enabled second factor and return OK when he didn't. This is not 
> the best solution, which would be some script which decides which 
> factors are required by the user. This script would sit between 
> kerberos auth and the other factors.

I think that is a cleaver solution for doing this on the central 
weblogin server, and as long as you are happy with this solution, I 
think it should be fine.

As you have discovered, cosign does not have a central database for 
storing user configuration and controlling the user's experience 
centrally.  Instead, it is up to each individual cosign-protected web 
server to say what it requires the user to have.

We have a web service here where the second factor is required not only 
for certain users, but also only for certain POST data.  It's a 
ticketing system where the second factor is only required if the user is 
accessing a sensitive ticket queue and also has a privileged role with 
respect to that queue.  We made a small change to the web app that looks 
up the queue number and the user role for that queue, and if the queue 
is marked as sensitive and the user has elevated privileges, the web app 
redirects the user to the central weblogin server for reauthenication 
using the second factor, in the exact same way as the cosign filter 
redirects users.  As you can see, this is a case where the second factor 
is enabled only for specific users instead of services, but we leave the 
decision up to the service, and initiate the action from the service.  
Even though this is not what you want, I hope the idea is helpful.

--
   Mark Montague
   m...@catseye.org


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss


Re: [Cosign-discuss] Conditional Factors

2013-01-22 Thread Florian Mueller
>
> > 1) Is there any way to bypass the logout verification screen? I really
> don't need verification when I redirect
> > the user from a service logout script to central logout.
>
> Not at the moment, no. Please file a feature request on the cosign tracker:
>
> http://p.sf.net/cosign/tracker


Thank you. I implemented it by myself. I will send a patch when it's ready.


> > 2) I haven't already tried (because my setup is not ready) but is it
> possible to authenticate against kerberos
> > using email-addresses? I don't need the friend feature. But I expect the
> friend factor to steal the credentials
> > if login is an email-address.
>
> Yes. Use the "passwd" keyword in your cosign.conf:
>
> passwd kerberos (.+)@.+   $1   MY.KRB5.REALM
> passwd kerberos  ([^@]+)   $1   MY.KRB5.REALM
>
> The top pattern should cause the cgi to extract krb5 principal names from
> e-mail addresses; the second pattern is the standard kerberos principal
> matching rule used by the cgi.


OK, this is cool, will use that, thanks.


>

> 3) Is there a possibility to make the google-auth factor required for all
> services and not just the ones which
> > define it inside the filter.
>
> Not yet. Cosign's current multifactor implementation is service-driven:
> the protected service determines how much authentication is required before
> granting access. There's work underway to add hooks to the cgi requiring
> multifactor authN depending on which user is authenticating.
>

Yeah, this would be cool. Luckily the cosign code is more or less
understandable so I can hack such features by myself until they made it
into master.

Florian
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss


Re: [Cosign-discuss] Conditional Factors

2013-01-22 Thread Florian Mueller
Hi Steve

Yes, I did configured the factor as secondary (-2) but the problem was that
I didn't know how to enable factors only for specific users instead of
services. In our environment the user should be able to decide whether he
wants to use Google Authenticator or not.

But in the meantime I solved it by enabling the factor in all services and
query some database inside the factor which determines whether the user
enabled second factor and return OK when he didn't. This is not the best
solution, which would be some script which decides which factors are
required by the user. This script would sit between kerberos auth and the
other factors.

Florian

On 10 January 2013 16:49, Bennett, Steve  wrote:

>  Hi Florian,
>
> ** **
>
> We’re in the process of trialling two-factor authentication for some of
> our services – we’re mostly using hardware tokens but we also support
> software tokens like Google Authenticator – it’s all relatively
> straightforward.
>
> ** **
>
> We have multiple routes for validating a one time password, including
> using CoSign to allow a webapp to request OTP as an additional factor, as
> you describe (i.e. something like “CosignRequreFactor OTP” on the webapp
> side)
>
> ** **
>
> The drawback you describe doesn’t occur if you configure the OTP factor as
> secondary (option ‘-2’ in cosign.conf):
>
> *  If the user is authenticating to a non-OTP service they’ll not be
> required to submit an OTP.
>
> *  If the user later visits a service that does require OTP, the user will
> be shown the login page with the OTP field visible, and will only be
> required to satisfy **that** factor (since the primary factor is already
> provided).
>
> *  If the user hasn’t already authenticated for their primary factor (or
> if the webapp has requested re-authentication) the user is prompted for
> both password and OTP in one go, and the OTP validation will only be
> attempted if the password validation succeeds.
>
> *  The javascript on the default template hides and shows the fields as
> they are required to prevent user confusion.
>
> ** **
>
> One point that took us a few months to realise (and nearly cost us a lot
> of money) is that many hardware tokens use the same algorithm as Google
> Authenticator (i.e. HOTP/TOTP), so you may be able to buy the tokens
> off-the-shelf and use the reference code on googlecode, rather than pay a
> supplier lots of money for a proprietary library that does little more than
> the algorithm described in RFC4226.
>
> ** **
>
> --
>
> Steve Bennett, Lancaster University****
>
> ** **
>
> *From:* Florian Mueller [mailto:flo2muel...@gmail.com]
> *Sent:* 08 January 2013 12:03
> *To:* cosign-discuss@lists.sourceforge.net
> *Subject:* [Cosign-discuss] Conditional Factors
>
> ** **
>
> Hi all,
>
> ** **
>
> I have set up kerberos and cosign to work correctly with username and
> password. Now I'd
>
> like to setup two-factor authentication using google authenticator.
>
> ** **
>
> The setup should be like this:
>
> ** **
>
> 1) User is presented a login page with just username & password on it
>
> 2) User enters correct credentials
>
> 2.1) An additional factor gets called which determines the required
> two-factor method
>
> for the user via LDAP or similar (database).
>
> 3) User is presented a login page with just the form field for auth-token.
> 
>
> 4) User enters correct token and is authenticated.
>
> ** **
>
> Is it possible to achieve this? ATM I only see the possibility to enable
> the two-factor
>
> auth based on CosignRequiresFactor and the user has to post all data
> (user, password, token)
>
> inside one request, which is not handy when authentication methods may
> differ between users.
>
> ** **
>
> Is there any way I can get something like this to work or is cosign the
> wrong tool for such
>
> a setup?
>
> ** **
>
> Regards,
>
> Florian
>
>
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> ___
> Cosign-discuss mailing list
> Cosign-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>
-

Re: [Cosign-discuss] Conditional Factors

2013-01-17 Thread Andrew Mortensen

On Jan 9, 2013, at 5:33 AM, Florian Mueller  wrote:

> ...Maybe you find the time to answer three more questions?
> 
> 1) Is there any way to bypass the logout verification screen? I really don't 
> need verification when I redirect
> the user from a service logout script to central logout.

Not at the moment, no. Please file a feature request on the cosign tracker:

http://p.sf.net/cosign/tracker

> 2) I haven't already tried (because my setup is not ready) but is it possible 
> to authenticate against kerberos
> using email-addresses? I don't need the friend feature. But I expect the 
> friend factor to steal the credentials
> if login is an email-address.

Yes. Use the "passwd" keyword in your cosign.conf:

passwd kerberos (.+)@.+   $1   MY.KRB5.REALM
passwd kerberos  ([^@]+)   $1   MY.KRB5.REALM

The top pattern should cause the cgi to extract krb5 principal names from 
e-mail addresses; the second pattern is the standard kerberos principal 
matching rule used by the cgi.

> 3) Is there a possibility to make the google-auth factor required for all 
> services and not just the ones which
> define it inside the filter.

Not yet. Cosign's current multifactor implementation is service-driven: the 
protected service determines how much authentication is required before 
granting access. There's work underway to add hooks to the cgi requiring 
multifactor authN depending on which user is authenticating.

andrew


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss


Re: [Cosign-discuss] Conditional Factors

2013-01-10 Thread Bennett, Steve
Hi Florian,

We're in the process of trialling two-factor authentication for some of our 
services - we're mostly using hardware tokens but we also support software 
tokens like Google Authenticator - it's all relatively straightforward.

We have multiple routes for validating a one time password, including using 
CoSign to allow a webapp to request OTP as an additional factor, as you 
describe (i.e. something like "CosignRequreFactor OTP" on the webapp side)

The drawback you describe doesn't occur if you configure the OTP factor as 
secondary (option '-2' in cosign.conf):
*  If the user is authenticating to a non-OTP service they'll not be required 
to submit an OTP.
*  If the user later visits a service that does require OTP, the user will be 
shown the login page with the OTP field visible, and will only be required to 
satisfy *that* factor (since the primary factor is already provided).
*  If the user hasn't already authenticated for their primary factor (or if the 
webapp has requested re-authentication) the user is prompted for both password 
and OTP in one go, and the OTP validation will only be attempted if the 
password validation succeeds.
*  The javascript on the default template hides and shows the fields as they 
are required to prevent user confusion.

One point that took us a few months to realise (and nearly cost us a lot of 
money) is that many hardware tokens use the same algorithm as Google 
Authenticator (i.e. HOTP/TOTP), so you may be able to buy the tokens 
off-the-shelf and use the reference code on googlecode, rather than pay a 
supplier lots of money for a proprietary library that does little more than the 
algorithm described in RFC4226.

--
Steve Bennett, Lancaster University

From: Florian Mueller [mailto:flo2muel...@gmail.com]
Sent: 08 January 2013 12:03
To: cosign-discuss@lists.sourceforge.net
Subject: [Cosign-discuss] Conditional Factors

Hi all,

I have set up kerberos and cosign to work correctly with username and password. 
Now I'd
like to setup two-factor authentication using google authenticator.

The setup should be like this:

1) User is presented a login page with just username & password on it
2) User enters correct credentials
2.1) An additional factor gets called which determines the required two-factor 
method
for the user via LDAP or similar (database).
3) User is presented a login page with just the form field for auth-token.
4) User enters correct token and is authenticated.

Is it possible to achieve this? ATM I only see the possibility to enable the 
two-factor
auth based on CosignRequiresFactor and the user has to post all data (user, 
password, token)
inside one request, which is not handy when authentication methods may differ 
between users.

Is there any way I can get something like this to work or is cosign the wrong 
tool for such
a setup?

Regards,
Florian
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss


Re: [Cosign-discuss] Conditional Factors

2013-01-09 Thread Florian Mueller
Hi Andrew

Thanks for your answer. As a matter of fact I had no idea that cosign
caches already satisfied factors.

With that knowledge and some changes in cosign.js it's possible to
implement the desired behavior.
My google-auth factor exits with status OK when authenticated user has no
google auth configured
or when OTP is correct. In the UI I specify factors which should only be
displayed when there was a
successful kerberos-auth. This results in a nice workflow where user first
enters login and password
and then receives a screen with just the token field because there is a
factor missing. Maybe this
sounds a little bit hacky.

Thanks again!

Maybe you find the time to answer three more questions?

1) Is there any way to bypass the logout verification screen? I really
don't need verification when I redirect
the user from a service logout script to central logout.

2) I haven't already tried (because my setup is not ready) but is it
possible to authenticate against kerberos
using email-addresses? I don't need the friend feature. But I expect the
friend factor to steal the credentials
if login is an email-address.

3) Is there a possibility to make the google-auth factor required for all
services and not just the ones which
define it inside the filter.

Regards,
Florian

On 8 January 2013 17:01, Andrew Mortensen  wrote:

> Hi Florian. You're right: what you describe is currently not possible in
> cosign. That doesn't mean it won't be, though. As a matter of fact, there's
> work underway at a university to add a feature to cosign that matches your
> scenario almost exactly. There's a chance this will be available in the
> relatively near future. Your input would be helpful as this feature is
> shaped.
>
> Cosign's multifactor login support is more flexible than you might think.
> If a user logs in first, either simply by visiting the login page or by
> visiting a protected service requiring only one factor, and the user
> subsequently visits a service requiring additional factors, the weblogin
> server will demand only the factor(s) that have not yet been authenticated.
>
> andrew
>
>
>
> On Jan 8, 2013, at 7:03 AM, Florian Mueller  wrote:
>
> > Hi all,
> >
> > I have set up kerberos and cosign to work correctly with username and
> password. Now I'd
> > like to setup two-factor authentication using google authenticator.
> >
> > The setup should be like this:
> >
> > 1) User is presented a login page with just username & password on it
> > 2) User enters correct credentials
> > 2.1) An additional factor gets called which determines the required
> two-factor method
> > for the user via LDAP or similar (database).
> > 3) User is presented a login page with just the form field for
> auth-token.
> > 4) User enters correct token and is authenticated.
> >
> > Is it possible to achieve this? ATM I only see the possibility to enable
> the two-factor
> > auth based on CosignRequiresFactor and the user has to post all data
> (user, password, token)
> > inside one request, which is not handy when authentication methods may
> differ between users.
> >
> > Is there any way I can get something like this to work or is cosign the
> wrong tool for such
> > a setup?
> >
> > Regards,
> > Florian
> >
> --
> > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> > and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> > 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> > SALE $99.99 this month only - learn more at:
> >
> http://p.sf.net/sfu/learnmore_122512___
> > Cosign-discuss mailing list
> > Cosign-discuss@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>
>
> --
> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only - learn more at:
> http://p.sf.net/sfu/learnmore_122512
> ___
> Cosign-discuss mailing list
> Cosign-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss


Re: [Cosign-discuss] Conditional Factors

2013-01-08 Thread Andrew Mortensen
Hi Florian. You're right: what you describe is currently not possible in 
cosign. That doesn't mean it won't be, though. As a matter of fact, there's 
work underway at a university to add a feature to cosign that matches your 
scenario almost exactly. There's a chance this will be available in the 
relatively near future. Your input would be helpful as this feature is shaped.

Cosign's multifactor login support is more flexible than you might think. If a 
user logs in first, either simply by visiting the login page or by visiting a 
protected service requiring only one factor, and the user subsequently visits a 
service requiring additional factors, the weblogin server will demand only the 
factor(s) that have not yet been authenticated.

andrew



On Jan 8, 2013, at 7:03 AM, Florian Mueller  wrote:

> Hi all,
> 
> I have set up kerberos and cosign to work correctly with username and 
> password. Now I'd
> like to setup two-factor authentication using google authenticator.
> 
> The setup should be like this:
> 
> 1) User is presented a login page with just username & password on it
> 2) User enters correct credentials
> 2.1) An additional factor gets called which determines the required 
> two-factor method
> for the user via LDAP or similar (database).
> 3) User is presented a login page with just the form field for auth-token.
> 4) User enters correct token and is authenticated.
> 
> Is it possible to achieve this? ATM I only see the possibility to enable the 
> two-factor
> auth based on CosignRequiresFactor and the user has to post all data (user, 
> password, token)
> inside one request, which is not handy when authentication methods may differ 
> between users.
> 
> Is there any way I can get something like this to work or is cosign the wrong 
> tool for such
> a setup?
> 
> Regards,
> Florian
> --
> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only - learn more at:
> http://p.sf.net/sfu/learnmore_122512___
> Cosign-discuss mailing list
> Cosign-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss


--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss


[Cosign-discuss] Conditional Factors

2013-01-08 Thread Florian Mueller
Hi all,

I have set up kerberos and cosign to work correctly with username and
password. Now I'd
like to setup two-factor authentication using google authenticator.

The setup should be like this:

1) User is presented a login page with just username & password on it
2) User enters correct credentials
2.1) An additional factor gets called which determines the required
two-factor method
for the user via LDAP or similar (database).
3) User is presented a login page with just the form field for auth-token.
4) User enters correct token and is authenticated.

Is it possible to achieve this? ATM I only see the possibility to enable
the two-factor
auth based on CosignRequiresFactor and the user has to post all data (user,
password, token)
inside one request, which is not handy when authentication methods may
differ between users.

Is there any way I can get something like this to work or is cosign the
wrong tool for such
a setup?

Regards,
Florian
--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss