Expiring password conundrum

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Expiring password conundrum

Lipscomb, Gary
Hi all,

We have configured Shibboleth IdP (v3.4.6) to check for expiring passwords triggered by our openLDAP password policy.
All works as planned. The user is warned that their password is expiring and given the options to

1. click on the link to change their password
2. clink on the link to continue to the original site
3. wait 20 seconds before being sent to the original site.


The issue we are seeing is that if a user clicks on the change password link they are presented with another IdP login page since our change password page is protected by Shibboleth and also the original request hasn't completed (its waiting 20 seconds before meta-refresh). If they enter their credentials again they get the expiring password message scenario.

Is there a way to complete the original IdP login process when clicking on the link to change password so the user doesn't have to re-enter their credentials.

If they have an expired, or locked password due to login failures we provide a link to another site not protected via Shibboleth.

Regards

Gary

Gary Lipscomb
Technical Officer, Systems(Infrastructure) | Infrastructure & Client Services | Division of Information Technology
Charles Sturt University
Panorama Avenue
Bathurst NSW 2795
Tel: +61 2 6338 6533
Email: [hidden email] |www.csu.edu.au




|   ALBURY-WODONGA   |   BATHURST   |   BRISBANE   |   CANBERRA   |   DUBBO   |   GOULBURN   |   MELBOURNE   |   ORANGE   |   PORT MACQUARIE   |   SYDNEY   |   WAGGA WAGGA   |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with Charles Sturt University may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at Charles Sturt University. The views expressed in this email are not necessarily those of Charles Sturt University.
Charles Sturt University in Australia The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Consider the environment before printing this email.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Expiring password conundrum

Peter Schober
* Lipscomb, Gary <[hidden email]> [2019-10-10 05:36]:
> If they have an expired, or locked password due to login failures we
> provide a link to another site not protected via Shibboleth.

Why not use that same "other site" for changing passwords, too?

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Expiring password conundrum

Losen, Stephen C (scl)
In reply to this post by Lipscomb, Gary
Hi Gary,

Are you using the expiring-password intercept ? It runs after the user has authenticated on the IDP. So if this intercept displays a page with a link to your password change app, then the user has an IDP session and gets in without authenticating again on the IDP. Within the intercept config you need to "whitelist" the entityID of your password change app to avoid showing the page again, i.e., behave as if the user's password is not about to expire.

Steve Losen
ITS - Enterprise Infrastructure
University of Virginia
[hidden email]    434-924-0640


-----Original Message-----
From: users <[hidden email]> On Behalf Of Lipscomb, Gary
Sent: Wednesday, October 9, 2019 11:36 PM
To: Shib Users <[hidden email]>
Subject: Expiring password conundrum

Hi all,

We have configured Shibboleth IdP (v3.4.6) to check for expiring passwords triggered by our openLDAP password policy.
All works as planned. The user is warned that their password is expiring and given the options to

1. click on the link to change their password 2. clink on the link to continue to the original site 3. wait 20 seconds before being sent to the original site.


The issue we are seeing is that if a user clicks on the change password link they are presented with another IdP login page since our change password page is protected by Shibboleth and also the original request hasn't completed (its waiting 20 seconds before meta-refresh). If they enter their credentials again they get the expiring password message scenario.

Is there a way to complete the original IdP login process when clicking on the link to change password so the user doesn't have to re-enter their credentials.

If they have an expired, or locked password due to login failures we provide a link to another site not protected via Shibboleth.

Regards

Gary

Gary Lipscomb
Technical Officer, Systems(Infrastructure) | Infrastructure & Client Services | Division of Information Technology Charles Sturt University Panorama Avenue Bathurst NSW 2795
Tel: +61 2 6338 6533
Email: [hidden email] |www.csu.edu.au




|   ALBURY-WODONGA   |   BATHURST   |   BRISBANE   |   CANBERRA   |   DUBBO   |   GOULBURN   |   MELBOURNE   |   ORANGE   |   PORT MACQUARIE   |   SYDNEY   |   WAGGA WAGGA   |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with Charles Sturt University may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at Charles Sturt University. The views expressed in this email are not necessarily those of Charles Sturt University.
Charles Sturt University in Australia The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018 Consider the environment before printing this email.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Expiring password conundrum

Lipscomb, Gary
In reply to this post by Lipscomb, Gary
Hi Peter,

The change password is protect by Shibboleth SSO so it makes it easy for users to change their passwords.
The "other site" requires users to prove who they are and is multi-stepped. Not the best user experience on a regular basis.

Regards
Gary

-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Peter Schober
Sent: Thursday, 10 October 2019 21:44
To: [hidden email]
Subject: Re: Expiring password conundrum

* Lipscomb, Gary <[hidden email]> [2019-10-10 05:36]:
> If they have an expired, or locked password due to login failures we
> provide a link to another site not protected via Shibboleth.

Why not use that same "other site" for changing passwords, too?

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Expiring password conundrum

Lipscomb, Gary
In reply to this post by Lipscomb, Gary
Hi Steve,

We are using the expiring-password intercept.
The user arrives at the expiring-password.vm page and is presented with:


Charles Sturt University
Your password will be expiring soon!

To create a new password now, go to Change my password.

Your login will proceed in 20 seconds or you may click here to continue.

Copyright 2019 Charles Sturt University CRICOS 00005F


When they click on the "create a new password now" link they are asked to authenticate again. This is the bit I'm failing to understand. They have already authenticated when trying to access the original site, but the IdP hasn't proceeded to complete the process and redirect to it. Its waiting for the 20 second meta-refresh.

I'll have a look at the whitelisting in the meantime.

Regards

Gary

-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Losen, Stephen C (scl)
Sent: Friday, 11 October 2019 00:43
To: Shib Users <[hidden email]>
Subject: RE: Expiring password conundrum

Hi Gary,

Are you using the expiring-password intercept ? It runs after the user has authenticated on the IDP. So if this intercept displays a page with a link to your password change app, then the user has an IDP session and gets in without authenticating again on the IDP. Within the intercept config you need to "whitelist" the entityID of your password change app to avoid showing the page again, i.e., behave as if the user's password is not about to expire.

Steve Losen
ITS - Enterprise Infrastructure
University of Virginia
[hidden email]    434-924-0640


-----Original Message-----
From: users <[hidden email]> On Behalf Of Lipscomb, Gary
Sent: Wednesday, October 9, 2019 11:36 PM
To: Shib Users <[hidden email]>
Subject: Expiring password conundrum

Hi all,

We have configured Shibboleth IdP (v3.4.6) to check for expiring passwords triggered by our openLDAP password policy.
All works as planned. The user is warned that their password is expiring and given the options to

1. click on the link to change their password 2. clink on the link to continue to the original site 3. wait 20 seconds before being sent to the original site.


The issue we are seeing is that if a user clicks on the change password link they are presented with another IdP login page since our change password page is protected by Shibboleth and also the original request hasn't completed (its waiting 20 seconds before meta-refresh). If they enter their credentials again they get the expiring password message scenario.

Is there a way to complete the original IdP login process when clicking on the link to change password so the user doesn't have to re-enter their credentials.

If they have an expired, or locked password due to login failures we provide a link to another site not protected via Shibboleth.

Regards

Gary

Gary Lipscomb
Technical Officer, Systems(Infrastructure) | Infrastructure & Client Services | Division of Information Technology Charles Sturt University Panorama Avenue Bathurst NSW 2795
Tel: +61 2 6338 6533
Email: [hidden email] |www.csu.edu.au




|   ALBURY-WODONGA   |   BATHURST   |   BRISBANE   |   CANBERRA   |   DUBBO   |   GOULBURN   |   MELBOURNE   |   ORANGE   |   PORT MACQUARIE   |   SYDNEY   |   WAGGA WAGGA   |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with Charles Sturt University may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at Charles Sturt University. The views expressed in this email are not necessarily those of Charles Sturt University.
Charles Sturt University in Australia The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018 Consider the environment before printing this email.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Expiring password conundrum

Cantor, Scott E.
On 10/10/19, 5:37 PM, "users on behalf of Lipscomb, Gary" <[hidden email] on behalf of [hidden email]> wrote:

> When they click on the "create a new password now" link they are asked to authenticate again. This is the bit I'm failing
> to understand. They have already authenticated when trying to access the original site, but the IdP hasn't proceeded to
> complete the process and redirect to it. Its waiting for the 20 second meta-refresh.

The interceptor runs after it's saved the authentication results off into the user's session, but client sessions don't get updated until the very end, so a request to a different server and the creation of a new container session will end up without knowledge that the authentication happened.

However, use of the LDAP account state approach to detecting these conditions has nothing to do with the interceptor and is a different mechanism. You said you were using account state. You probably aren't using both, or shouldn't be, anyway.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Expiring password conundrum

Wessel, Keith William
Gary,

Any chance the password change SP is requesting forced reauthentication?

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Thursday, October 10, 2019 4:49 PM
To: Shib Users <[hidden email]>
Subject: Re: Expiring password conundrum

On 10/10/19, 5:37 PM, "users on behalf of Lipscomb, Gary" <[hidden email] on behalf of [hidden email]> wrote:

> When they click on the "create a new password now" link they are asked to authenticate again. This is the bit I'm failing
> to understand. They have already authenticated when trying to access the original site, but the IdP hasn't proceeded to
> complete the process and redirect to it. Its waiting for the 20 second meta-refresh.

The interceptor runs after it's saved the authentication results off into the user's session, but client sessions don't get updated until the very end, so a request to a different server and the creation of a new container session will end up without knowledge that the authentication happened.

However, use of the LDAP account state approach to detecting these conditions has nothing to do with the interceptor and is a different mechanism. You said you were using account state. You probably aren't using both, or shouldn't be, anyway.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Expiring password conundrum

Lipscomb, Gary
In reply to this post by Cantor, Scott E.
Hi Keith,

The change password page is not forcing re-authentication. If I wait for the original page to complete and then use the same link for the change password then SSO kicks' in and I'm not prompted for authentication

Hi Scott,

You are right, we are not using the interceptor, just the errors codes presented by openLDAP and the standard password flow  with the changes mentioned here
https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-HandlingaccountstatewithOpenLDAP

Regards

Gary

-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Wessel, Keith
Sent: Friday, 11 October 2019 09:08
To: Shib Users <[hidden email]>
Subject: RE: Expiring password conundrum

Gary,

Any chance the password change SP is requesting forced reauthentication?

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Thursday, October 10, 2019 4:49 PM
To: Shib Users <[hidden email]>
Subject: Re: Expiring password conundrum

On 10/10/19, 5:37 PM, "users on behalf of Lipscomb, Gary" <[hidden email] on behalf of [hidden email]> wrote:

> When they click on the "create a new password now" link they are asked to authenticate again. This is the bit I'm failing
> to understand. They have already authenticated when trying to access the original site, but the IdP hasn't proceeded to
> complete the process and redirect to it. Its waiting for the 20 second meta-refresh.

The interceptor runs after it's saved the authentication results off into the user's session, but client sessions don't get updated until the very end, so a request to a different server and the creation of a new container session will end up without knowledge that the authentication happened.

However, use of the LDAP account state approach to detecting these conditions has nothing to do with the interceptor and is a different mechanism. You said you were using account state. You probably aren't using both, or shouldn't be, anyway.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Expiring password conundrum

Cantor, Scott E.
On 10/10/19, 6:18 PM, "users on behalf of Lipscomb, Gary" <[hidden email] on behalf of [hidden email]> wrote:

> You are right, we are not using the interceptor, just the errors codes presented by openLDAP and the standard
> password flow  with the changes mentioned here

And in that case, authentication isn't actually done yet, totally different situation.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Expiring password conundrum

Lipscomb, Gary
In reply to this post by Lipscomb, Gary
Thanks Scott,
The light now flickers

Gary

-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Cantor, Scott
Sent: Friday, 11 October 2019 09:25
To: Shib Users <[hidden email]>
Subject: Re: Expiring password conundrum

On 10/10/19, 6:18 PM, "users on behalf of Lipscomb, Gary" <[hidden email] on behalf of [hidden email]> wrote:

> You are right, we are not using the interceptor, just the errors codes presented by openLDAP and the standard
> password flow  with the changes mentioned here

And in that case, authentication isn't actually done yet, totally different situation.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]