|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
Wicket and Single Sign-on?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@... For additional commands, e-mail: users-help@... |
|
|
Re: Wicket and Single Sign-on?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<jeff.longland@...> 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@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
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<igor.vaynberg@...> 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<jeff.longland@...> 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@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Wicket and Single Sign-on?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<jeff.longland@...> 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<igor.vaynberg@...> 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<jeff.longland@...> 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@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
| Free embeddable forum powered by Nabble | Forum Help |