Stateless consumer

[christian.rivasseau]

Hi,

I have been wondering what is the techniques to perform verification
in stateless mode.
(Simple example in the quickStart makes use of


// retrieve the previously stored discovery information
DiscoveryInformation discovered = (DiscoveryInformation)
session.getAttribute("discovered");
...
VerificationResult verification = _consumerManager.verify
(receivingURL.toString(), openidResp, discovered);

where discovered is retrieved from the session.


Any hint ?

[Johnny Bufu]

On Fri, Jul 03, 2009 at 09:50:19AM -0700, christian.rivasseau wrote:
> I have been wondering what is the techniques to perform verification
> in stateless mode.

Verification is performed transparently by the ConsumerManager
regardless of the stateless mode; there's nothing extra to configure for
it.

Stateless mode can be disabled with
ConsumerManager.setAllowStateless(false).

Stateless mode can be required with
ConsumerManager.setMaxAssocAttempts(0).

Johnny

[christian.rivasseau]

OK,

I'm just confused about what should be the last argument to
consumerManager.verify since I have no discovered
from the session ?

Tried null :

org.openid4java.discovery.DiscoveryException: 0x500: Cannot parse
identifier: null
at org.openid4java.discovery.Discovery.parseIdentifier(Discovery.java:
106)
at org.openid4java.discovery.Discovery.discover(Discovery.java:114)
at org.openid4java.consumer.ConsumerManager.discover
(ConsumerManager.java:527)


I'm just wondering if it's possible to perform openid without keeping
any state on the server ?

[Johnny Bufu]

On Fri, Jul 03, 2009 at 12:15:34PM -0700, christian.rivasseau wrote:
> I'm just confused about what should be the last argument to
> consumerManager.verify since I have no discovered
> from the session ?
>
> Tried null :

If there's no previously discovered info, null should be used.

> org.openid4java.discovery.DiscoveryException: 0x500: Cannot parse
> identifier: null
> at org.openid4java.discovery.Discovery.parseIdentifier(Discovery.java:
> 106)
> at org.openid4java.discovery.Discovery.discover(Discovery.java:114)
> at org.openid4java.consumer.ConsumerManager.discover
> (ConsumerManager.java:527)

It looks like you're passing a null identifier to discover(), the
failure is expected in this case.

> I'm just wondering if it's possible to perform openid without keeping
> any state on the server ?

If by server you mean RP / Consumer, than yes it is possible.

Johnny

[rafaelDeitos]

Hi, I'm having a similar problem:

Let's say I want to have my RP implementation running on a cluster.
I cannot guarantee that after the user is redirected to the OpenID
provider he will get back to the same machine (same instance of the
consumer manager, for example).
I've seen that the ConsumerManager keeps the association "inMemory"...

You mentioned it is possible to do OpenID without keeping the state on
the RP... how do I do this?

Thanks
Rafael

[caska...@gmail.com]

Hello!

Is there any solution for this problem? I have a similar situation
where I'd like to use OpenID for authentication of a fairly disparate
system where multiple web service providers will receive requests from
a client and need not know of any previous session in order to fulfill
requests.

Thanks,
Jean-Philippe

[Chandra Tondepu]

How is OpenID different from any other web application we host?  Shouldnt the sticky session bit enabled at the load-balancer be routing the user always to the same application server?   

If the ConsumerManager can persist the association in memory, based on the OP-identifier/claimed identifier, it will become much easier to retrieve the association from persistence store to redirect the user.   I haven't yet reached this point yet in my implementation but I am hoping this should do.

Regds, Chandra.

[Jean-Philippe Steinmetz]

Unfortunately we're not building a regular web application so relying on the load balancer to always direct a user to the same server where their session is stored is not a viable solution. In my scenario we will have a web app that will authenticate the user for us and pass along the information to the client. Then the client should use the information in each subsequent HTTP request header as it communicates with the varying servers. In essence we want single sign on authentication where we can pass the user from place to place without keeping track of where they are or how they got there. As long as the client passes a valid authenticated ticket the server will fulfill the request. In other words we are doing a kerberos model but with OpenID. From what I understand OpenID can provide this type of functionality. My question is how do I get there?

[Chandra Tondepu]

Did you encounter this problem? Or do you see this as a potential problem?  

My understanding is that the OpenID need not maintain any stateful associations, however, it offers Single Sign On because of the verification of the assertion which ensures the signature is validated.

Particularly in the case of stateless association, the Relying Party shall ask the OpenID Provider to verify the association based on the handle the OP has....

Let me know what you see with this....

Regds, Chandra.

[Jean-Philippe Steinmetz]

I'm merely looking for guidance on how to implement this code of solution. So far all of the examples I have seen and mailing list postings are in regards to using OpenID is a stateful mode. While i've heard one just has to enable stateless I have not seen any descriptions or explanations of how to read the OpenID information from an HTTP request headers that comes in to my web service.

[Johnny Bufu]

On Tue, Sep 22, 2009 at 10:59:29AM -0700, Jean-Philippe Steinmetz wrote:
> I'm merely looking for guidance on how to implement this code of solution.
> So far all of the examples I have seen and mailing list postings are in
> regards to using OpenID is a stateful mode. While i've heard one just has to
> enable stateless I have not seen any descriptions

To make sure we're on the same page, "stateless" in OpenID context means
no associations maintained by the RP (the OP will do the signature
verification).

For cluster deployments that do not guarantee that clients are
redirected back to the same RP hosts, there are two options:

1. Stateless mode can be enforced, via ConsumerManager.setMaxAssocAttempts(0)
Note that this option comes with two drawbacks:
- verification will be slower, since an extra call to the OP is required
for each message
- won't work for OpenID 1.x messages, where the ConsumerManager enforces
the use of (in-memory) RP nonces (for security reasons)

2. The RP can be configured to use database-backed stores for the
associations and RP nonces (the JdbcConsumerAssociationStore and
JdbcNonceVerifier).

> or explanations of how to
> read the OpenID information from an HTTP request headers that comes in to my
> web service.

OpenID does not use HTTP headers for the OpenID specific payload of the
messages. See sections 4 and 5 (Data Formats and Communication Types) of
the specification.

Johnny