You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jeff Longland <je...@gmail.com> on 2009/07/05 14:26:22 UTC
Re: Wicket and Single Sign-on?
Hi Igor,
Apologies that I wasn't more detailed. More specifically:
1. User is in application X
2. User clicks on link to goto application Y
3. Application X constructs a URL with relevant parameters (ex.
username) and an md5 hash with the shared secret
4. Application X redirects to this URL.
5. Application Y (the wicket app) receives the request and validates
the shared secret. (authentication)
6. After validating the shared secret, the user needs to be logged in
with the appropriate role (authorization)
7. User proceeds to use the application
When working with JSP/Servlet previously, I've accomplished this by
using a servlet filter on application Y. As I said in my original
post, I'm not sure what the 'proper' way of doing something like this
is with Wicket. Can anyone offer any guidance?
Thanks again,
Jeff
On Thu, Jun 18, 2009 at 11:23 PM, Igor Vaynberg<ig...@gmail.com> wrote:
> saying that you will use MAC doesnt really say HOW you are going to
> implement sso.
>
> if you are going to use CAS, at least from what i understand of it,
> here is one way the integration can work:
>
> user is on a page
> they click a link that requires login
> your iauthorizationstrategy implementation detects that next action
> requires login, it checks for CAS token, doesnt see it, it then
> records the current url and issues a 302 to CAS passing in the current
> url as a callback
>
> user sees CAS login page
> user authenticates
> CAS redirects back to the callback url
>
> the url again causes your iauthorizationstrategy implementation to
> wake up. this time it sees the CAS token and lets the action proceed.
>
> -igor
>
> On Thu, Jun 18, 2009 at 7:51 PM, Jeff Longland<je...@gmail.com> wrote:
>> I'm relatively new to Wicket and trying not to carry forward any
>> preconceived notions from other frameworks. What is the
>> suggested/preferred means of authenticating single sign-on requests
>> from another application? In particular, I'm thinking about MAC
>> (http://en.wikipedia.org/wiki/Message_authentication_code) but could
>> potentially use a proper single sign-on framework ala CAS. I've
>> searched the list and saw some mention of using a servlet filter? Any
>> guidance would be appreciated.
>>
>> Thanks,
>> Jeff
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and Single Sign-on?
Posted by Igor Vaynberg <ig...@gmail.com>.
application X constructs a url to page Y of the wicket app.
application X issues a redirect
wicket's IAuthorizationStrategy intercepts instantiation of page Y
inside this strategy you can check if the url contains proper credentials
if it does you store the credentials in session and return true -
meaning user has access to page Y
-igor
On Sun, Jul 5, 2009 at 5:26 AM, Jeff Longland<je...@gmail.com> wrote:
> Hi Igor,
>
> Apologies that I wasn't more detailed. More specifically:
>
> 1. User is in application X
> 2. User clicks on link to goto application Y
> 3. Application X constructs a URL with relevant parameters (ex.
> username) and an md5 hash with the shared secret
> 4. Application X redirects to this URL.
> 5. Application Y (the wicket app) receives the request and validates
> the shared secret. (authentication)
> 6. After validating the shared secret, the user needs to be logged in
> with the appropriate role (authorization)
> 7. User proceeds to use the application
>
> When working with JSP/Servlet previously, I've accomplished this by
> using a servlet filter on application Y. As I said in my original
> post, I'm not sure what the 'proper' way of doing something like this
> is with Wicket. Can anyone offer any guidance?
>
> Thanks again,
> Jeff
>
> On Thu, Jun 18, 2009 at 11:23 PM, Igor Vaynberg<ig...@gmail.com> wrote:
>> saying that you will use MAC doesnt really say HOW you are going to
>> implement sso.
>>
>> if you are going to use CAS, at least from what i understand of it,
>> here is one way the integration can work:
>>
>> user is on a page
>> they click a link that requires login
>> your iauthorizationstrategy implementation detects that next action
>> requires login, it checks for CAS token, doesnt see it, it then
>> records the current url and issues a 302 to CAS passing in the current
>> url as a callback
>>
>> user sees CAS login page
>> user authenticates
>> CAS redirects back to the callback url
>>
>> the url again causes your iauthorizationstrategy implementation to
>> wake up. this time it sees the CAS token and lets the action proceed.
>>
>> -igor
>>
>> On Thu, Jun 18, 2009 at 7:51 PM, Jeff Longland<je...@gmail.com> wrote:
>>> I'm relatively new to Wicket and trying not to carry forward any
>>> preconceived notions from other frameworks. What is the
>>> suggested/preferred means of authenticating single sign-on requests
>>> from another application? In particular, I'm thinking about MAC
>>> (http://en.wikipedia.org/wiki/Message_authentication_code) but could
>>> potentially use a proper single sign-on framework ala CAS. I've
>>> searched the list and saw some mention of using a servlet filter? Any
>>> guidance would be appreciated.
>>>
>>> Thanks,
>>> Jeff
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org