Just to build on what Marvin said, please note that whatever additional parameters you specify, they should NOT EVER be service specific because authentication does NOT happen per service. You'll cause all sorts of problems if you think that authentication occurs per service.
If you need those attributes later on, they should be stored in the Authentication object after authentication which means a custom AuthenticationMetaDataPopulator (or whatever its called. We rarely use it so I often forget the name :-)). Cheers, Scott On Tue, May 5, 2009 at 7:45 AM, Marvin Addison <[email protected]>wrote: > > I need to get extra params from Authentication Handler which we are > taking > > extra values against DB according to username/password. But the problem > was > > authenticateUsernamePasswordInternal method is returning only > true/false…. > > Authentication handlers are designed to be extended. If the built-in > UsernamePasswordAuthenticationHandler is not > sufficient, you should develop your own. If you're taking additional > parameters, you should probably develop a new Credentials class to > store the additional parameters as well and ensure that your custom > handler supports this type of credential. I'm pretty certain that > some careful source review will make it clear you can easily > accomplish your objectives. Some pseudocode to get you started: > > public class UsernamePasswordCredentialsAndMore extends > UsernamePasswordCredentials { > > public setParam1() {...} > public setParam2() {...} > } > > public class CustomAuthenticationHandler implements AuthenticationHandler { > public boolean supports(Credentials credentials) { > return credentials instanceof UsernamePasswordCredentialsAndMore; > } > > public boolean authenticate(Credentials credentials) { > final UsernamePasswordCredentialsAndMore upcAndMore = > (UsernamePasswordCredentialsAndMore) credentials; > // Your custom authentication logic here > } > } > > > And also I need to get those values in Service class - public Response > > getResponse(final String ticketId) to response to service provider. > > You probably don't want to go that route as stated. A better > alternative would be to make your DB a source of attributes, and > configure your client to validate tickets at /samlValidate so that the > attributes can be delivered to the client. > http://www.ja-sig.org/wiki/display/CASUM/Attributes is a good starting > point for how you would configure the server to release attributes. > You may have to dig a bit to translate the instructions into something > appropriate for an RDBMS source, but that should be supported. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
