[OWASP-ESAPI] IUser and RSAToken
Gunnar Peterson
gunnar at arctecgroup.net
Tue Jan 8 00:36:03 EST 2008
So the authentication is between the user and the identity provider. And
this produces a claim that is sent to the esapi: (something like below) -
point is that ³all² you have to do is build a relying party on the esapi
side, instead of embedding hooks to every authN protocol from here to east
jesus. The identity selector¹s job is to prove the identity and the esapi¹s
job is to verify the claim who sent it? When? What was signed? And so
on...
<enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<enc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<enc:EncryptedKey>
<enc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<dsig:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
</enc:EncryptionMethod>
<dsig:KeyInfo>
<wsse:SecurityTokenReference
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
ty-secext-1.0.xsd">
<wsse:KeyIdentifier
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.
1#ThumbprintSHA1"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-m
essage-security-1.0#Base64Binary">zHXxYr8jTDe/UhznC81ixsQXSpI=</wsse:KeyIden
tifier>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
<enc:CipherData>
<enc:CipherValue>hgBNzEXXnoLNu6DPhXJanirEPOK/ey53RKISJrwvRhQazPBgqcnZPaxNVqZ
f6TOR1VbryCU6fbGw
jIuuXzTb5Z+0PsRPM4N8CLSBxYxN1BFCNnhW67qJ4zrw72OTIkkTLWvPDpJpAak6X6RGFteaf3zD
uVYU4Ta0sDmMD6lxgjs=</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedKey>
</dsig:KeyInfo>
<enc:CipherData>
<enc:CipherValue>qCiqGzgr9JKl8hQXKBkZ7d+CIDmppKGTQgTYCjgT1/jR/...
See -
http://xmldap.blogspot.com/2006/03/how-to-consume-tokens-from-infocard.html
On 1/7/08 10:37 PM, "Jim Manico" <jim at manico.net> wrote:
>> > 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)
>
> Would this require a plugin, or a browser setting change, or both?
>
>> > The esapi just needs to validate the claims that are sent and provide
>> protection.
>
> I'm stuck at
> a) the technology-specific authentication is offloaded away from EASPI?
> in conflict with
> b) ESAPI would need to verify the offloaded authentication?
>
> Best,
> Jim
>
>
>> Re: [OWASP-ESAPI] IUser and RSAToken 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>
>> <mailto: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]
>>> <mailto:gunnar at arctecgroup.net%5D>
>>> 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>
>>> <mailto: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]
>>> <mailto:owasp-esapi-bounces at lists.owasp.org%5D> 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.h
>>>> tml
>>> 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]
>>> <mailto:owasp-esapi-bounces at lists.owasp.org%5D> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.516 / Virus Database: 269.17.13/1213 - Release Date: 1/7/2008
>> 9:14 AM
>>
--
Gunnar Peterson, Managing Principal, Arctec Group
http://www.arctecgroup.net
Blog: http://1raindrop.typepad.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20080107/45b755d5/attachment-0001.html
More information about the OWASP-ESAPI
mailing list