28 messages in org.oasis-open.lists.security-servicesRe: ForceAuthn (was Use Cases)| From | Sent On | Attachments |
|---|---|---|
| Beach, Michael C | Oct 23, 2003 12:49 pm |  .bin, .doc |
| John Kemp | Nov 24, 2003 1:58 pm | |
| Beach, Michael C | Nov 25, 2003 11:24 am | |
| Greg Whitehead | Nov 25, 2003 11:50 am | |
| Beach, Michael C | Nov 25, 2003 12:24 pm | |
| Greg Whitehead | Nov 25, 2003 12:32 pm | |
| John Kemp | Nov 26, 2003 6:20 am | |
| Scott Cantor | Nov 26, 2003 8:22 am | |
| John Kemp | Nov 27, 2003 7:49 am | |
| Scott Cantor | Nov 28, 2003 9:30 pm | |
| Conor P. Cahill | Nov 29, 2003 2:14 am | |
| Conor P. Cahill | Nov 29, 2003 2:25 am | |
| Conor P. Cahill | Nov 29, 2003 2:27 am | |
| John Kemp | Nov 29, 2003 5:54 am | |
| Conor P. Cahill | Nov 29, 2003 11:35 am | |
| Beach, Michael C | Nov 29, 2003 11:37 am | |
| John Kemp | Nov 29, 2003 11:52 am | |
| Beach, Michael C | Nov 29, 2003 11:59 am | |
| Beach, Michael C | Nov 29, 2003 12:03 pm | |
| Conor P. Cahill | Nov 29, 2003 1:46 pm | |
| Conor P. Cahill | Nov 29, 2003 2:59 pm | |
| Anthony Nadalin | Nov 30, 2003 5:23 pm | |
| Conor P. Cahill | Nov 30, 2003 7:18 pm | |
| Conor P. Cahill | Dec 1, 2003 4:16 am | |
| Anthony Nadalin | Dec 1, 2003 9:31 pm | |
| Conor P. Cahill | Dec 2, 2003 4:38 am | |
| Anthony Nadalin | Dec 3, 2003 4:36 am | |
| Conor P. Cahill | Dec 3, 2003 4:54 am |
| Subject: | Re: ForceAuthn (was Use Cases) | |
|---|---|---|
| From: | John Kemp (onez...@bcn.net) | |
| Date: | Nov 27, 2003 7:49:20 am | |
| List: | org.oasis-open.lists.security-services | |
On Wednesday, Nov 26, 2003, at 11:28 US/Eastern, Scott Cantor wrote:
without requiring any global protocol to manage it. With the ability to force re-authentication at a certain time after the previous authentication, through the protocol, they get even more control over this process. I've cc'd Scott who's working on the SSO requirements to make sure he sees this.
I guess the question I have is one I've seen raised before, namely what exactly does ForceAuthn mean? How can the IdP have that kind of control when there are authentication technologies that make it impossible to know for sure whether the user will even be prompted.
Well, your point is certainly well taken, but I guess I wasn't necessarily equating ForceAuthn with "InteractWithUser". To me, all this says is for the IdP to at least check the authentication status of the user, following *their* policy. This may include a user interaction, but as you point out below, it may not. So, perhaps the term 'ForceAuthn' is somewhat misleading?
Client certs are tops on that list, since the cert store usually caches the PIN and repeatedly authenticates with the key for a length of time, often controlled by the browser, not the IdP.
But this may be the case regardless of the setting of ForceAuthn, no?
Even basic-auth behaves this way, though the IdP can work around that one with a challenge header.
So even if you grant that the SP can somehow "bypass" what we would normally consider to be SSO processing, that's fairly distinct from actually reauthenticating the user in a real sense. Or is the implication that the IdP MUST insure that this happens and cannot rely on technologies that don't provide that assurance if the Force flag is present?
I think you are saying that ForceAuthn=true implies that the IdP actually interact with the user, and that such an interaction is the only way of re-authenticating the user in a real sense. And, I don't know that we could ever get that kind of effect within the protocol itself, for the reasons you have noted. But, I also think that in an environment where a "real" authentication is important to the SPs, that ForceAuthn may very well imply that the IdP will not depend on cached cert PINs or other methods where a user interaction is not required.
- JohnK