RE: [provision] Re: ForgotMyPassword (was "Re: [provision] use case for

Hi Gary- yes that’s exactly it. The SPML client isn’t the end user, it’s a web application written in the language du jour that uses SPML as its web services payload for all things provisioning. The authentication of the web application to the SPML service still needs to be done but that’s usually on the HTTP or SOAP message layer or both.

A lot of the low lying fruit for SPML implementation is within the enterprise as an integration tool. Let’s face it, COTS IDM applications tend to have ugly web interfaces. Let the web designers do what they do, and have the IDM service points implement SPML and solve easy problems like forgotten password recovery. Then we’re providing simple solutions to simple problems and gain traction and interest….

From: Gary Cole [mailto:gary.cole@oracle.com]
Sent: Tuesday, January 04, 2011 10:40 AM
To: Hal Lockhart; Richard Sand
Cc: OASIS PSTC
Subject: Re: [provision] Re: ForgotMyPassword (was "Re: [provision] use case for extended password reset capabilities")

My question is: Why expose ForgotMyPassword over *SPML*? (Re-reading what I wrote earlier, I realize that I should have emphasized that aspect of the question.) As I mentioned below, an individual end-user is not typically a requester. Also, if ForgotMyPassword service is exposed over HTTP, then that *application* could be authorized to make the requests to get questions, check answers and change the password of the end-user. Is the business trying to centralize not only identity information but also the policies related to passwords (so that enforcement is uniform)?

On Jan 3, 2011, at 1:07 PM, Hal Lockhart wrote:

The typical password reset scenario is this: Every user is expected to control an email account which is associated with the userid at registration time. The password reset request causes the password to be set to a random value and marked for single use only (user must change the password after signing in.) The random password is then sent to the email account associated with the userid.

The criterion for making this request is often nothing, since the only threat is a mild denial of service. (Mild because the user can be told when he tries to login that his password has been reset and directed to look in his in basket.) It is possible to require answers to questions in order to make this request, but it seems to me that this is going to be an application e.g. HTTP/html flow rather than an SPML one.

Hal

-----Original Message-----
From: Gary Cole
Sent: Monday, December 20, 2010 4:42 PM
To: Richard Sand
Cc: OASIS PSTC
Subject: [provision] Re: ForgotMyPassword (was "Re: [provision] use case for extended password reset capabilities")
Richard, I forgot to ask one very important question earlier: What is the actual use-case here? That is, what business problem is the customer trying to solve (by exposing ForgotMyPassword over SPML)?

An individual end-user is not typically a requester. (A typical requester is an application or another business-unit, partner or supplier.) The trust-model for an end-user is a little weird, since most end-users would not map to identities with administrative rights in the Provider. The Provider would have to perform authorization (i.e., to scope appropriately the end-user's access to information-objects within the Provider). The trust-model for an UNAUTHENTICATED END-USER is even trickier: since the Provider cannot really trust an unauthenticated user, the Provider must limit very carefully the information that it reveals (lest it provide an attack-point that a program could use to guess passwords).

An application that acts as an SPML Requester could support ForgotMyPassword by getting questions and answers from the central server (SPML Provider) securely and then performing secondary authentication (e.g., security Q&A) itself. Once the application confirms the end-user's answers, the application could request from the Provider an administrative setPassword for the end-user.

So, then, what is the motivation for a Provider to expose an end-user ForgotMyPassword capability? Is the idea that the customer is trying to centralize not only identity information but also the policies that govern the quality and number of secondary-authentication questions that must be answered by an end-user?

On Dec 20, 2010, at 10:23 AM, Gary Cole wrote:

This is a good idea. ForgotMyPassword is a very common use-case. We can fuss over the details later. (Because the implicit requestor in this scenario is an unauthented end-user, rather than a proxied administrator, we may want to make this a separate ForgotMyPassword capability. Also, something like the <challengeId> you mentioned may be very useful in correlating challenge-answers with multiple challenge-questions. )

Do we also want a ForgotMyLoginName function? The provider could do a lookup (i.e., search) based on email-address or some other identifier. If the value of the identifier is non-unique, or if the value is not found, we might want to return an error to indicate this, but we'd have to be careful not to give an attacker a tool for guessing email addresses or passwords. As you suggested, some sort of token might be useful.

Gary

On Dec 20, 2010, at 9:58 AM, Richard Sand wrote:

Hi all,
I’ve been promising this for awhile… one of the use cases that we’ve had multiple clients consider implementing via SPML is for forgotten password reset and/or recovery. Its an example of a use case where we can add some “higher level” capability to SPML so that it supports the identity-management operations that many applications provide, instead of just lower level atomic operations.
The existing set and resetPassword operations can be extended to cover forgotten password reset/recovery by adding elements for challenge/response questions and answers, and we can also add an operation for querying for challenge questions for a given PSOID.
Some hacked up non-normative examples:
<resetPasswordRequest requestID=”135”>
<psoID ID=”rsand”/>
<challenge>
                <question>What was the color of your first car</question>
                <answer>black</answer>
</challenge>
</resetPasswordRequest>
Of course there could be multiple challenge elements.
The process of challenging for a password reset often requires statefulness over two or more requests, so a generic token element can be used to maintain state. It can also be used for example by captcha mechanism if the PSP wishes to enforce such a mechanism there (as opposed to just leaving it up to the application). A flow could go something like:
1)      Request for pwd reset challenge
<resetPasswordRequest requestID=”135”>
<psoID ID=”rsand”/>
<challenge/>
</resetPasswordRequest>
2)      Response with challenge and token
<resetPasswordResponse requestID=”135”>
<token>xyzH1</token>
<challenge>
                <question>What was the color of your first car</question>
</challenge>
</resetPasswordResponse >
3)      Request for pwd reset with challenge answers and token
<resetPasswordRequest requestID=”136”>
<psoID ID=”rsand”/>
<token>xyzH1</token>
<challenge>
                <question>What was the color of your first car</question>
                <answer>black</answer>
</challenge>
</resetPasswordRequest>
There are a lot of ways to express the above with different semantics – I just made those up as ideas. The point is that its flexible and still allows the PSP to determine what the challenge system is that it supports. For example some clients may have “buckets” of questions where the user must select 1 question of out 5 from each of 3 buckets – I can see adding an optional “challengeid” attribute of the challenge element to enable the systems to perform multiple challenges in the same transaction for this.
The existing (re)setPassword functionality allows for the end user changing their own password by supplying the old password. We could also add an element or perhaps an attribute to the request element that specifies what type of identity is making the request – is it an administrator or is it the end user? But also the notion of request metadata, which is a separate topic altogether, could meet that need.
Anyway look forward to your thoughts and comments. But this in general is the kind of thing I want to add to SPML – elements that are specific to higher level IDM functions like self registration, enable/disable of accounts, self-service request access to a role, etc.
Thoughts?
Richard Sand | CEO
239 Kings Highway East | Haddonfield | New Jersey 08033 | USA
Mobile: +1 267 984 3651| Office: +1 856 795 1722| Fax: +1 856 795 1733

<image001.jpg>

provision message