Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] proposal to change IContext.open semantics

To me IContext.open(null) sounds like the context doesn't need authn materials, i.e. can be opened by anyone. reopen() sounds better to me.

But no strong opinion..

Markus

On Tue, Aug 5, 2008 at 8:50 PM, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:

There have been some requests along the lines of IContext needing some kind of "re-authenticate" method.  The use case is something like:  The IdAS consuming application has already opened a context using a user's authN materials.  Some time has passed, or some policy has changed, and the application wishes to re-authenticate the user.


There is currently a way do do this (call IContext.close followed by IContext.open again with the authN materials previously provided by the user).  This requires the calling application to keep a copy of the authN materials.  The request is for there to be a way for the calling application to re-authenticate without re-providing the user's authN materials.


Currently, we say that if one calls IContext.open when a context is already in an open state, then a ContextOpenException is thrown.


The proposal is this:


1) Allow IContext.open to be called with a null authN materials.

2) When the above happens:

2.1) the context must be in an already open state or an AuthenticationException is thrown

2.2) the context provider will either:

2.2.1) use the previously passed authN materials to re-authenticate, or

2.2.2) throw an AuthenticationException, noting that it is unable to re-authenticate (this could be due to it not storing the previously used authN materials.


Objections?


Note that a followup question might be: "if we allow this, should we allow open to be called with new authN materials when a context is in an open state?"


Alternately, we could introduce a new method like IContext.reOpen().  That might cause the previous question to not be asked, and its semantics might be more immediately obvious.



Jim


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top