[OWASP-ESAPI] IUser and RSAToken

[Gunnar Peterson]

So the ESAPI implements a relying party. When the user wants to log in,
esapi relying party requests an infocard from the browser (they would need
to have this enabled in the browser), the big benefit is that it offloads
the technology-specific authentication and identity proofing from the esapi.
The esapi just needs to validate the claims that are sent and provide
protection.

-gp


On 1/7/08 9:23 PM, "Jeff Williams" <jeff.williams at owasp.org> wrote:

> How would this work?  Is there a way to get a ws-trust credentials out of the
> browser?
> 
>  
> --Jeff
>  
> 
> From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
> Sent: Monday, January 07, 2008 11:02 AM
> To: jeff.williams at owasp.org; 'Jim Manico'
> Cc: owasp-esapi at lists.owasp.org
> Subject: Re: [OWASP-ESAPI] IUser and RSAToken
>  
> Is there a reason you wouldn¹t use ws-trust to do this? This is precisely why
> it was invented
> 
> -support multiple token types ­ x.509 (if you are a sadist), saml (if you like
> xml), kerberos (if youlike dogs), and/or username/password (if you don¹t
> really care about security), or invent your own token
> 
> - simple request response methods to create a token and validate a token,
> 
> -gp
> 
> On 1/7/08 9:46 AM, "Jeff Williams" <jeff.williams at owasp.org> wrote:
> I¹m thinking an enterprise would only want to have the authentication methods
> they¹re actually using in *their* ESAPI.   I don¹t want an API that¹s so
> generic that it¹s impossible for any real developers to figure out and use.
> (I¹ve got plenty of JAAS and JCE scars).
> 
> 
> But I like Stephen¹s idea about using a Set of Credentials for the createUser
> and login method.  This would let the API be used with a bigger range of
> authentication approaches without making it ridiculously abstract.  I think we
> probably want to specify the type of the credentials, so ESAPI can know how to
> authenticate them.
>  
>  
> So it would work like thisŠ
>  
> -       The parameter names for the credentials can be specified in
> ESAPI.properties.
> 
> 
> -       ESAPI extracts credentials from the request and generate Credential
> objects
> 
> 
> -       ESAPI compares the credentials against the ones in the User object.
> 
> 
>  
> That¹s not a huge stretch for ESAPI ­ it already works like this for
> username/password.
>  
> Will that work to support the schemes you¹re thinking of?
>  
> --Jeff
>  
> 
> From: owasp-esapi-bounces at lists.owasp.org
> [mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Jim Manico
> Sent: Monday, January 07, 2008 3:23 AM
> Cc: owasp-esapi at lists.owasp.org
> Subject: Re: [OWASP-ESAPI] IUser and RSAToken
> 
> Cool. Right on Stephen (and Dan) May I invite you to take this to the next
> level?
> 
> How would you envision us going from a bunch of request data to hitting your
> suggested API? 
> 
> For example, here are a few situations I think we want work with
> 
> banking site:
> username
> password
> question_id
> answer_text
> (and the user would see an image for phishing verification, but would not be
> sent, but would be needed at createUser time)
> 
> RSA token auth:
> username
> password
> rsa_token_selection
> 
> standard enterprise app
> username
> password
> 
> Assuming these cases are consistent with what you are seeing, would you care
> to take your ideas a little deeper?
> 
> Thanks folks,
> Jim
> 
> 
> 
> I wasn't suggesting copying the whole implementation, just the bit about using
> an arbitrary number of Credentials per user.  E.g.:
> 
> public class Credential {
>     String name; 
>     Object value;
>     //getters and setters...
> } 
> 
> interface IUser {
>     void addUser(String username, String otherStuff.., Set<Credential> creds);
>     boolean login(Set<Credential> creds); //this compares the supplied set
> with the stored set
> } 
> 
> 
> On Jan 7, 2008, at 9:02 AM, Jim Manico wrote:
> 
> 
> 
> JAAS seems anything but intuitive to me - it's more for a servlet engine
> implementor or large commercial product.
> 
>> >From 
>> 
http://java.sun.com/javase/6/docs/api/javax/security/auth/spi/LoginModule.htm>>
l 
> initialize 
> public void initialize(Subject subject,
>                       CallbackHandler callbackHandler,
>                       Map sharedState,
>                       Map options)
> Initialize this LoginModule.
> This method is called by the LoginContext after this LoginModule has been
> instantiated. The purpose of this method is to initialize this LoginModule
> with the relevant information. If this LoginModule does not understand any of
> the data stored in sharedState or options parameters, they can be ignored.
> 
> 
> 
> Parameters: subject - the Subject to be authenticated. callbackHandler - a
> CallbackHandler for communicating with the end user (prompting for usernames
> and passwords, for example). sharedState - state shared with other configured
> LoginModules. options - options specified in the login Configuration for this
> particular LoginModule.
> 
> Stephen de Vries wrote:
> 
> 
> 
> I've not taken a close look at the ESAPI source, so I may be talking
> out of my 4rse here, but couldn't ESAPI use an arbitrary Set of
> credentials the way JAAS does?
> 
> 
> On Jan 7, 2008, at 5:27 AM, Jeff Williams wrote:
> 
> 
> 
> 
> Jim, 
> 
> Interesting. I'm trying to keep to just the methods that pretty much
> every 
> web application or web service would have to have. But I definitely
> understand the need for specialized User objects in most
> enterprises.  Do 
> you think we can come up with a way to handle these options in a way
> that 
> will be used in most apps?
> 
> I strongly encourage customization of the ESAPI for your enterprise.
> Actually, I expect every enterprise will need their OWN ESAPI. I would
> expect extensions like the ones you've proposed to the API itself (the
> interfaces).  And I expect them to rip, mix, and burn the reference
> implementation with their own services and internal needs.
> 
> I'm focused on the challenge of getting enterprises to agree that they
> should define and institutionalize an ESAPI.  If they use ours, or
> one based 
> on ours, then great.  But it's still great if they make up their own.
> 
> --Jeff 
> 
> -----Original Message-----
> From: owasp-esapi-bounces at lists.owasp.org
> [mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Jim Manico
> Sent: Sunday, January 06, 2008 5:19 AM
> To: owasp-esapi at lists.owasp.org
> Subject: [OWASP-ESAPI] IUser and RSAToken
> 
> Jeff, 
> 
> Many of the apps I'm writing for a certain large Enterprise involves a
> RSA token reference stored in the user profile. Would you suggest I
> extend the ESAPI user object, or  would you consider integrating this
> into EASPI in some way?
> 
> I'm thinking me might want a few different user types depending on the
> type of application:
> 
> 1) StandardUser (user, pass only)
> 2) BankingUser (user, pass, map of auth questions, phishing image id)
> 3) EnterpriseUser (user, pass, rsa token identifier)
> 
> In fact, there are several over User authentication possibilities (SSO
> tech, for example)
> 
> And I moving in the wrong direction by bringing these issues up?
> 
> - Jim 
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
> 
> 
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20080107/1b1aed0f/attachment-0001.html