<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
<TT>LS,</TT><BR>
<BR>
<BR>
<TT> I have a question about authenticating and verifying with OpenID</TT><BR>
<TT> but before i can ask my question i need to give a little background</TT><BR>
<TT> information.</TT><BR>
<BR>
<TT> We are currently building a centralised IDM/SSO solution which acts</TT><BR>
<TT> like a central store with profiles and handles authentication, it</TT><BR>
<TT> allows for traditional authentication as well as OpenID.</TT><BR>
<BR>
<TT> The central server usually requires some form of authentication</TT><BR>
<TT> before it can read or update a profile. Client websites simply use</TT><BR>
<TT> our API to authenticate and perform profile operations such as</TT><BR>
<TT> login, update or retrieve an active (SSO) profile to allow users to</TT><BR>
<TT> browse through all websites while still being logged in.</TT><BR>
<BR>
<TT> This all works very nice, but there is a little problem using</TT><BR>
<TT> OpenID.</TT><BR>
<BR>
<TT> I have implemented the authentication part of OpenID in the client,</TT><BR>
<TT> to allow redirection to your site or any other OpenID service</TT><BR>
<TT> provider.</TT><BR>
<BR>
<TT> After the redirection returns to the client website, it will pass</TT><BR>
<TT> the received HTTP GET parameters to the centralised IDM/SSO server</TT><BR>
<TT> which will then validate the authentication, this must be done at</TT><BR>
<TT> the server for i have no other alternative to actually identify an</TT><BR>
<TT> authentication otherwise.</TT><BR>
<BR>
<TT> The problem now is that it </TT><TT>__</TT><TT>sometim</TT><TT>es___</TT><TT> fails due to unknown reasons.</TT><BR>
<TT> It just says it cannot authenticate. Can you give me some advice?</TT><BR>
<BR>
<TT> To clarify, here is a simple overview of the flow:</TT><BR>
<BR>
<TT> 1) user-agent fills in OpenID URI at client site;</TT><BR>
<TT> 2) client site redirects to OpenID service provider;</TT><BR>
<TT> 3) service provider redirects back to client site;</TT><BR>
<TT> 4) client site collects HTTP query string parameters returned by the OpenID service provider;</TT><BR>
<TT> 5) client site calls central server and passes these parameters;</TT><BR>
<TT> 6) central server attempts to finalize the authentication by validating it and returns</TT><BR>
<TT> the profile or passes an exception.</TT><BR>
<BR>
<TT> Please note, client site can be any host and on any domain. The</TT><BR>
<TT> central server always resides on its own host or domain.</TT><BR>
<BR>
<TT> Would it be helpful to add the central server to the trust roots?</TT><BR>
<BR>
<TT> I patiently await your response.</TT><BR>
<BR>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-
Markus Jelsma Buyways B.V.
Technisch Architect Friesestraatweg 215c
<A HREF="http://www.buyways.nl">http://www.buyways.nl</A> 9743 AD Groningen
Alg. 050-853 6600 KvK 01074105
Tel. 050-853 6620 Fax. 050-3118124
Mob. 06-5025 8350 In: <A HREF="http://www.linkedin.com/in/markus17/">http://www.linkedin.com/in/markus17/</A>
</PRE>
</TD>
</TR>
</TABLE>
<BR>
</BODY>
</HTML>