ray at media.berkeley.edu
Wed Oct 26 09:28:36 PDT 2011
To flesh out Eli's note, I'm currently working on implementing the
following workflow for CalCentral:
1. Previously unknown user (with no OAE account) logs in through
external authentication. (CAS, in our case.)
2. Since the account is unknown, the user is identified as "anonymous"
so far as OAE is concerned, but the external identity is noted and
optionally triggers a redirect to a configurable self-registration
location. (In the current OAE code, the unknown user stops dead at a
blank page, thanks to the user ID not having even "anonymous" access to
3. At self-registration, the new user is shown the institutional data
which will be imported into the OAE (from Oracle, in our case) and given
the chance to join or to continue to browse.
4. While the user is externally-authenticated but unknown, "Sign out"
and "Join" links replace the usual "Sign in".
5. If the user agrees to join, then their account is created with all
integration data and their participant state is noted. (This involves
implementing a single-request method for full CalCentral account
creation, which currently requires a series of POSTs sent from a Ruby
script. Once that one-stop user creation service is available, it can
also be used by our automatic account-provision jobs.)
Obviously our local needs drive this but I'm trying to keep it
productizable. I'll let both lists know when I have the basic flow
implemented and maybe we can take it from there?
On 10/26/11 6:26 AM, Clay Fenlason wrote:
> The strategy of provisioning user info only after accepting terms is
> just the sort of thing we'd need at Georgia Tech as well. I think we
> each imagined that it was special local circumstances which prompted
> this kind of solution, but in practice we're finding that the need is
> rather general.
> I don't think the point is lost on anyone, but this looks to be a
> fairly textbook case of duplication of effort. What would it take,
> project leads, to incorporate a common solution, given that three
> independent ones have already been developed? My guess would be that
> this could be done with very low risk either technically or to the
> roadmap, but maybe I'm kidding myself.
> On Tue, Oct 25, 2011 at 4:44 PM, Eli Cochran, UC Berkeley
> <eli at media.berkeley.edu> wrote:
>> Sorry, forgot to include the link: http://www.screencast.com/t/L1ML83NxGrP
>> - Eli
>> On Tue, Oct 25, 2011 at 9:54 AM, Eli Cochran<eli at media.berkeley.edu> wrote:
>>> And, as promised, here is the screencast of Berkeley's "opt-in" dialog.
>>> In the current version we only support users who are already provisioned
>>> into CalCentral. The version we're working on now will support any user who
>>> has a CalNet ID (CAS). At the point where they opt-in, we will provision
>>> them into the system.
>>> - Eli
>>> On Oct 24, 2011, at 3:42 PM, Jeff Pasch wrote:
>>> Hi all,
>>> that Chris put together for us. We've thought about expanding this
>>> functionality to use it for delivering one time messages to users. For
>>> example, "The ATLAS Network has been upgraded to version 1.0.2. Click here
>>> for a list of enhancements...," to which the user would just click "ok".
>>> Let me know if you have any questions.
>>> Jeff Pasch
>>> Project Manager
>>> Information Technology Services
>>> New York University
>>> oae-production mailing list
>>> oae-production at collab.sakaiproject.org
>>> . . . . . . . . . . . . . . . . . .
>>> Eli Cochran
>>> project manager, CalCentral project
>>> manager of user experience design
>>> Educational Technology Services, UC Berkeley
>>> "Do not solve the problem that’s asked of you. It’s almost always the
>>> wrong problem."
>>> - Don Norman
>> oae-production mailing list
>> oae-production at collab.sakaiproject.org
> oae-production mailing list
> oae-production at collab.sakaiproject.org
More information about the oae-production