CLAIM-REQUEST user-credentials

[Ian Hummel]

NAME

user-credentials

DATATYPE

xsd:string

DESCRIPTION

The user's authentication credentials, in whatever format the IDP can provide them, such as plaintext or md5 encoded with 

some known salt.  This request leaves it the responsibility of the IDP and RP to negotiate a suitable format for the claim value.

RATIONALE

Using the PPID + digital signature of the token is not always an option for integrating i-cards into legacy applications.  

With this claim, IDPs have a well-known claim URI for issuing cards that can be integrated with legacy sign-on systems.

[Mike Jones]

I would be happier with a “password” claim that made it clear that the password was being passed in a specific way (even in the clear), than the current definition, if that’s what’s really going on here.  Not stating the representation of the credential means that cards utilizing this claim can not be used in an interoperable fashion.

 

Also, are these claim definitions hypothetical, or are they being proposed because of an actual deployment?  If no deployment is being considered, we should not be taking these up on a hypothetical basis.  If a deployment is imminent, please change the description to fully describe the data formats being used.  (Put another way, the rationale given below is hypothetical – not driven by a specific deployment need.)

 

BTW, as a matter of working group protocol, I think we’re supposed to have a claim discussion period before the formal claim request.

 

                                                                -- Mike

[Ian Hummel]

My understanding was that I initiated the discussion period... the other email is a CLAIM-VOTE email, right?

With respect to your questions, yes, this is for an imminent deployment.  A customer is using a legacy application built by a 3rd-party, impossible to change, which only accepts user name and password login.  We are building an i-card proxy essentially.

I am intentionally leaving the description of the claim values/formats up to the IDPs and RPs.  I'm not really anticipating a card with a user-identifier/user-credential pair as being useful at multiple RPs.

[Mike Jones]

If it’s username and password, the then claim names should specifically be “username” and “password”.

 

If it’s a non-auditing card where applies-to information is sent to the Identity Provider, then it’s entirely reasonable for the Identity Provider to consult a database of RP-specific usernames and passwords and supply the values that apply to that RP.  The IdP effectively then because (part of) a password manager.  (This is impossible for a non-auditing card, however you wouldn’t use a non-auditing card to hold site-specific information such as usernames and passwords in the first place.)

 

Hence, these can definitely be used at more than one site, and the claim definition should be written so as to accommodate that use case.

 

My misunderstanding about the discussion period.  Maybe we should use “CLAIM-DISCUSSION” rather than “CLAIM-REQUEST” to make this more obvious?

 

                                                                Cheers,

[John Bradley]

Ian,

If this is not intended to be interoperable, I question the value of putting it in the ICF catalog.

If this is a custom app where the RP is looking for a card from a specific issuer then it may be best to use claims from there own URI space.

In any event if it is a m-card then I don't see why the issuer cant use any algorithm they like for the PPID.  Make it an auditing card and have the STS put what would be effectively a username PPID.   From the RP point of view the password is the signing key of the STS.

Or are you trying to use the IdP/STS as a password manager to pass a actual username and password to some proxy gateway that will extract them for the legacy app?

If the latter is the case wouldn't you need two claims for that? 

=jbradley

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ICF-WG-Schemas" group.
To post to this group, send email to icf-wg-...@googlegroups.com
To unsubscribe from this group, send email to icf-wg-schema...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/icf-wg-schemas?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ian Hummel]

We can't modify the RP in anyway, so yes, we have to pass the actual username and password to some gateway.  We could use http://XX/username-and-password-separated-by-a-vertical-bar if we wanted to, but there are at least two deployments going live this month which include some kind of "user-id" claim.

[Axel Nennker]

Please read:
http://ignisvulpis.blogspot.com/2008/09/common-misconception-usernamepassword.html

It may not exactly fit your situation. Please excuse the words
"stupid" and "bad".
But still, if you can avoid this, then don't do this.

-Axel

repeated here:

People new to Information Cards sometimes think that Information Cards
are used to transport username and password to login at a relying
party....
Well, Information Cards could be used for that but this is a stupid
idea.

First it is incomprehension. Then you start to think: "Why not. This
could make the life of a relying party easier. They know how to handle
username and password, so let's give it to them". Bad idea.

When you use the security token to transport username and password and
you use nothing but username and password from the token then you are
giving away the advantages of the whole concept.
There need to be changes to the RP's software to disassemble the
security token anyway. When you accept this then you should accept
that you can then use the security features of the token too. Each
library that can disassemble the token can validate it too. It does
not hurt to check the validity dates of the security token. It does
not hurt to verify the signature of the security token. If the backend
system is so old and inflexible that you must provide two strings for
authentication then use a variation of e.g.: uid=PPID, pwd=public-key-
base64 or uid=username, pwd=PPID or uid=first-8-bytes-from-PPID, pwd=8-
bytes-from-public-key-hash-from-selected-but-fixed-positions. But you
must check the signature. Only the owner of the private key could sign
the security token and the private key is never transferred to the
anybody. This is THE advantage compared to username and password. You
can not forge the security token even if you know username and
password.

Don't invent username/password-tokens. Don't do evil.

[Ian Hummel]

I wish we lived in such an ideal world :-)

Unfortunately the software our customers have chosen to use was
written long, long ago... and we have to settle with what workarounds
are available to us at the moment.

- Ian.

[Ian Hummel]

Ok, let's try this again:

NAMES

* username

* password

DATATYPE

both are xsd:strings

DESCRIPTION

both username and password are strings, designed to allow backwards compatibility with legacy sign-on applications

RATIONALE

Certain legacy applications require a username and password to authenticate users. Unfortunately, many of these applications

cannot be upgraded to accept infocards as-is. A pair of username and password claims would allow an STS to issue tokens

with enough information to allow a proxy application to act as a bridge. The username and password claims could also

be used on auditing cards to enable services like e.g. Clipperz, which functions as a password manager, to issue the correct 

username and password claim values, depending on the target RP.

It should also be noted that even though a given username/password combination might not interoperate at any two random RPs,

at least both cards can use the same claim URI.

[Mike Jones]

I understand the business need for this in some circumstances, and would support this formulation.  Thanks Ian.

[John Bradley]

Better,

We need something to say that the STS  should validate the identity of the RP via the cert chain delivered with the RST.

This is to prevent phishing of the users credentials.

=jbradley 

[Axel Nennker]

Ian, could you please tell me more about your particular
"circumstances" so that I can understand the business need too?

I understand your scenario is:
- the STS has access to the user database that the RP uses too. Maybe
this is one db or two which are synchronized.
- this user-db exists and is filled with usernames and passwords that
you don't want to change.
- with RP you denote the legacy system that you can not change.
- you are writing an RP-proxy that triggers the infocard dance and
accepts security tokens.
- the proxy "posts" the U/P extracted from the token to the legacy
system, if successful the user now is "in-session".

Why are you not giving the proxy access to the user db too like the
STS? There could then be a new table in the db (or a new db at the
proxy) with the PPID as primary key and username and password in a
row. Then we would not need the new claims.

I really want to avoid the hellish U/P claims and I think that is
possible.

-Axel

> From: icf-wg-...@googlegroups.com<mailto:icf-wg-...@googlegroups.com> [mailto:icf-wg-...@googlegroups.com] On Behalf Of Ian Hummel
> Sent: Tuesday, January 27, 2009 1:19 PM
> To: icf-wg-...@googlegroups.com<mailto:icf-wg-...@googlegroups.com>
> Subject: [ICF.WG.Schemas] Re: CLAIM-REQUEST user-credentials
>
> My understanding was that I initiated the discussion period... the other email is a CLAIM-VOTE email, right?
>
> With respect to your questions, yes, this is for an imminent deployment.  A customer is using a legacy application built by a 3rd-party, impossible to change, which only accepts user name and password login.  We are building an i-card proxy essentially.
>
> I am intentionally leaving the description of the claim values/formats up to the IDPs and RPs.  I'm not really anticipating a card with a user-identifier/user-credential pair as being useful at multiple RPs.
>
> On Jan 27, 2009, at 4:10 PM, Mike Jones wrote:
>
> I would be happier with a "password" claim that made it clear that the password was being passed in a specific way (even in the clear), than the current definition, if that's what's really going on here.  Not stating the representation of the credential means that cards utilizing this claim can not be used in an interoperable fashion.
>

> Also, are these claim definitions hypothetical, or are they being proposed because of an actual deployment?  If no deployment is being considered, we should not be taking these up on a hypothetical basis.  If a deployment is imminent, please change the description to fully describe the data formats being used.  (Put another way, the rationale given below is hypothetical - not driven by a specific deployment need.)

>
> BTW, as a matter of working group protocol, I think we're supposed to have a claim discussion period before the formal claim request.
>
>                                                                 -- Mike
>

[Ian Hummel]

Hi Axel,

The STS does not have access to the user DB. It only has access to a
service that says "Yes/No the username password are correct"

- Ian.

[Axel Nennker]

How can this be? The STS issues a security token that contains your
new claims. Therefore it must have access to username and password.
Where are the values for your new claim coming from if not from the
STS?
confused,
Axel

[Ian Hummel]

It is a username and password backed card, the STS has access to the
username and password via the RST.

[Axel Nennker]

Abusing the username/password from the STS authentication for this is
"considered harmful".
The coupling between legacy RP, this Information Card, proxyRP and STS
would be so tight that using that information card at another service
would become insecure.

The claims based approach is diametral contrary to this use case.
This concept is raping the claims idea.

-Axel

[Ian Hummel]

Sorry you feel that way Axel, but I appreciate your passion on this issue :-)

I would be happy to incorporate any positive feedback under the claim "Rational" section before pushing this for a vote.  I have updated it below to mention that auditing cards should be favored.

RATIONALE

Certain legacy applications require a username and password to authenticate users.  Unfortunately, many of these applications cannot be upgraded to accept infocards as-is.  A pair of username and password claims would allow an STS to issue tokens with enough information to allow a proxy application to act as a bridge, and thus create a consistent login experience for users.  The username and password claims could also be used on auditing cards to enable services like e.g. Clipperz, which functions as a password manager, to issue the correct username and password claim values, depending on the target RP.

It should also be noted that even though a given username/password combination might not interoperate at any two random RPs, at least both cards can use the same claim URI.  Also, to maximize security the STS should issue an auditing card, check the certificate of the RP is known, and encrypt the token with the RPs certificate before releasing the token.

[John Bradley]

Ian,

Is the IdP/STS storing one or more username password pairs for the card and selecting them based on the "Client Pseudonym"/RP CN?  

Or are you trying to store the user name/Password in the m-card and pass them to the STS in the RST.

I was under the impression that you were attempting the former.

If you are passing the password from the RST to the RP then the card could only be used at one RP.

I need to think if this is a good idea or not.

On the other hand this WG is not intended to police bad ideas only the claims themselves.

As long as the two claims are clear and can be reused in an interoperable manner I don't think we should block the claims.

How the IdP/STS gets the password is something best debated in IdP/RP  best practices.

=jbradley

--~--~---------~--~----~------------~-------~--~----~

[John Bradley]

The wording check that the RP is known should include "check that the RP certificate is valid and select the appropriate username/password for the RP.  RPs must not be sent username/passwords configured for other sites."

Encrypting it with a subject restriction is good.

Keeping this phishing resistant is a concern of mine once we start treading these waters.

I sympathize with Axel's concerns but understand the business need.

=jbradley

[John Bradley]

Ian,

OK lets see if I understand this.

The Site is the one issuing the m-cards.

The Site's STS contains no claims for the card.

The users username for the site is included in the m-card.

The RP's WS-Policy requests a card from a specific issuer with username and password as required claims.

The selector triggers and using the embedded username asks the user for there password.

This password as well as the username are sent in the RST to the RP's STS.

The Site's STS validates that the request came from itself and then returns a audience restricted token with the username and password in the username and password fields.

The Sites RP code then receives the token and posts the username and password to the legacy app creating a session cookie for the user.

Do I have it now?

In the above my advice would be to stick to private claim URI.   

I can see an argument for ICF interoperable ones but the above is not the use case for that.

Not being interoperable is actually a security feature in this case.  It also stops the selector from presenting the card as an option at other sites.    

I would also not include the PPID as a claim on the m-card if you can avoid it, this stops it from coming up if some other RP only asks for a PPID claim.  

I hope this helps.

=jbradley

 

On 28-Jan-09, at 12:37 PM, Ian Hummel wrote:

The STS doesn't store anything, anywhere.  It is a transparent proxy.  The username and password come in, the username and password come out.

This is absolutely limited to one STS/RP.

The only reason i proposed the claims to the ICF is so that we can use well-known URIs for these claims, because I figured this is going to be a pretty popular use case... how else are we supposed to enable legacy app signon with information cards?

[Axel Nennker]

John, I agree and you explained it better than my short sentence:

"The coupling between legacy RP, this Information Card, proxyRP and
STS
would be so tight that using that information card at another service
would become insecure."

The card should not show up in the selector at another RP and this is
best ensured when the claims are private to this RP/STS pair.

I would even go so fare to suggest that we add a paragraph to the
claims page that explictely describes this use case and that suggests
that random private claims are best suited to be used here.

-Axel

> ...
>
> Erfahren Sie mehr »
>
>  smime.p7s
> 3KAnzeigenHerunterladen

[Pamela Dingle]

Regardless of whether this is a best practice or not, it makes sense that these kinds of claims will be needed and used. 

Could we perhaps do something slightly petty and append the word "legacy" to the front to fully convey our royal displeasure to those using?

:)

Call me a control freak - but if we're going to define a claim, we should try to define that claim such that people could pick it up and interoperate with it, yes?  If so, I would suggest that a straight password claim should dictate rigor -- ie md5-password as the claimname or SHA1password.

In the case of user-credentials, again perhaps we could create a best practice around this that would allow people to make some assumptions about the quality and makeup of the claim value.   For example, if you were to fill this value with an encrypted piece of xml containing one or more legacy credential claims, then folks would know what to expect, if not exactly what they were giving or getting.

I'm coming into this late, so perhaps these comments are out of place.  Hopefully you get the drift in any case :)

Cheers,

Pamela

[John Bradley]

Pam,

Ian is looking to send a text password so yes if this goes ahead that should be clear.

If you send a MD5 or SHA1 of the password you also need to send the salt to make it useful so you would ether need a complex value for those claims or yet another claim.

The RP itself will be validating the claim against some password database so that is probably sufficient to gauge the claims authenticity.

As far as I can tell the goal is to use a m-card to provide some phishing protection for legacy apps without modifying the legacy app.

My take on this is that as the cards are not intended to be interoperable, private URI should be used by the IdP.

The long term stability of the URI is not required as they only need to exist for as long as the STS is using them.

I think a generic password manager card is a separate issue.   

If someone presents a use case for that then we can argue the merits of the idea then.

I am waiting for a response from Ian on the message below.   If private URI work then I think this one is closed.

=jbradley

[Axel Nennker]

Hi Ian,

you write about "a consistent login experience for users" this is a
good thing.
I conclude from this that there are more then just this one legacy
application.

Could you please share more info about the whole scenario? I guess
that many of us will have to architect IdM in similar situations like
your current example.
I guess that all applications are in one domain? Are your applications
using domain cookies to keep state?
Do you have webaccess to the "change password form" of the legacy
application(s)?. ...

thanks
Axel