Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] How specify the authentication method in the Relying Party Security Policy

Yep, I understand that.  If you do what I suggested, and specify a distinct issuer, the card selector will also only show the user the correct card... no need to have those extra claims.

What's more, if you do have those claims, what prevents an IdP from lying about them?

answer:  you validate the certificate of the IdP... in which case you know the IdP, and presumably how it authenticates the user, and thus why would you still need a "howUserWasAuthenticated" claim?

Again, I suggest you set up two IdPs... one with username and password, one with x509 auth.  Both IdPs can have the same claims, and even the same backing data store.

Your RP should be configured to only accept cards from those two IdPs... and it should use the certificate (e.g. the digital identity of the service) to discern which privileges a user @ the RP should have.

Of course each IdP needs a unique certificate.


Does the scenario above accomplish what you're looking for?



On May 14, 2009, at 11:41 AM, Leonardo Straniero wrote:

Hi John, hi Ian, hi all,
 
Thanks for your responses.
 
(For Ian) I refer at the authentication method at the IdP, I know the RP uses the security token to authenticate the user.
 
The idea is to create two new claims, for example “weak” and “strong”.
If the user uses the Username/Password authentication method the IdP set true the claim “weak”; otherwise if the user uses the X509 credentials to authenticate at the IdP the “strong” claim is setted at true. Then if I insert the “weak” or “strong” claim into the requestedClaim into the RP Policy, the Cardspace (or any other Identity Selector) can display to the user only the card with X509 Credential or UsernamePassword Credentials for IdP authentication.
 
But how I can implements this solution? I don’t know where and if it is possible.

Any ideas are appreciated.

Best Regards.
       Leonardo.
 
From: John Bradley [mailto:ve7jtb@xxxxxxxxxx] 
Sent: giovedì 14 maggio 2009 16.43
To: Higgins (Trust Framework) Project developer discussions
Cc: leonardo.straniero@xxxxxxxxxxxx
Subject: Re: [higgins-dev] How specify the authentication method in the Relying Party Security Policy
 
In IMI 1.1 we will be looking at adding support for more of WS-SecurityPolicy to allow for describing a set of issuers and the claims that would be required from each of them.
 
At the moment you could define claims that relate to LoA values.  Perhaps the NIST ones thy seem popular.
 
You could then make NIST 1 a required claim so that only cards containing it would be presented to the user.
 
The RP then has to decide if it trusts the issuer to make that claim.   There are people looking at those issues now.
 
Trying to expose the m-card authentication method to the RP is counter to the direction things are moving.
 
Regards
John Bradley
 
On 14-May-09, at 10:29 AM, Ian Hummel wrote:


Hi Leonardo,
 
I think there is a bit of a disconnect in what you are asking for.  It doesn't feel "right" to me (from an infocard perspective).
 
For starters, if you are running an RP you do not authenticate your users with a username/password, or even with an x509 certificate.  You authenticate your users with the SAML token that is submitted.  THAT is the credentials that determine whether or not you let the user in.  The entire ws-trust protocol is designed to shield you from how the user authenticates to the IDP.  Do not fight the protocol!
 
If you want to separate between "strong" and "weak" authenticated individuals on your site, and yet have both classes authenticate via the same mechanism (SAML token) the correct way is to trust two different issuers.
 
You would have two object tags on your page, like this:
 
<object type="application/x-informationCard" name="xmlToken">
            <param name="issuer" value="https://example.com/strong/x509/auth/trust/service">
            <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion">
            <param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
</object>
 
<object type="application/x-informationCard" name="xmlToken">
            <param name="issuer" value="https://example.com/weak/usernamepassword/auth/trust/service">
            <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion">
            <param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
</object>
 
 
I understand your desire to enforce more fine grained authentication requirements on the IDPs that your RP trusts... this is possible in WS-Trust by using a special Ws-Policy file, unfortunately the web profile of the infocard spec does not allow access to the full ws-policy, only the simplified version that you see above.
 
- ian.
 
 
 
 
On May 14, 2009, at 5:28 AM, Leonardo Straniero wrote:


Hi Chris, hi All,

We want add a new Claim when a user create a new account on the IdP site (e.g Webpage claim, or "strong authentication", please see the previous mail). Is it possible? How I can configure the IdP for this scope? I tried to manually modify the xml configuration files with a text editor but when I create a new account I get this LDAP error:

          Error creating user ID 'jhon': javax.naming.directory.InvalidAttributeIdentifierException: [LDAP: error code 17 - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage: AttributeDescription contains inappropriate characters]; remaining name 'cn=jhon,ou=identities,dc=project,dc=eu' 
I added the webpage attribute in the LDAP schema.

Another question: is it possible retrieve the authentication method on the IdP (e.g. X509 Certificate, UsernamePassword, PersonalCard) from the security token returned? Is necessary modify any other settings for this purpose? We need to know the authentication method on the IdP to support or not only the X509Certificate authentication method.

Any Ideas?

Any suggestion will be appreciated.

Thanks in advance.

Best Regards.
            Leonardo.

-----Original Message-----
From: Christopher Taylor [mailto:christopher.taylor@xxxxxxxxxxxxxxxxxxx] 
Sent: martedì 12 maggio 2009 16.34
To: leonardo.straniero@xxxxxxxxxxxx; Higgins (Trust Framework) Project developer discussions
Subject: Re: [higgins-dev] How specify the authentication method in the Relying Party Security Policy

Leonardo Straniero schrieb:

Hi Chris,
thanks for the explanation and prompt reply.
Could you please clarify me how can I manage a situation such the following one.
Suppose that the RP needs to dynamically change the type of authentication a user has to do (e.g. from username/PWD or X509certificate to X509 certificate only) against the IdP.
 
like I said, that's not really possible. The RP trusts that the 
identities it recieves from the IdP are authentic. The steps the IdP 
undertakes to ensure this (i.e. what kind of authentication it uses) are 
- from the viewpoint of the RP - out of scope.

My idea was to simply have different RP policies one for "weak authentication" and another one for the strong case. These policies, in my humble opinion, just had to have a statement whose value is different like the ones I exemplified in my previous posting.
So I was figuring to be able to restrict access to the RP in certain situation to only users having X509 certificates cards.
You said the RP has no way to do this, right? Or can  I add some "required claims" in the RP "strong authentication" policy that makes possible to force the IdP (or CardSpace) to only accepts users with X509 certificate cards?
 
There's a couple of ways you could do this:
- you could have the policy specify an STS of which you *know* that it 
uses X.509 for authentication.
- you could require some custom claim in the policy, e.g.
 * http://example.org/auth/#x509
 * http://example.org/auth/#unpw
 however, the RP has no way to check that the user did indeed use this 
authentication method, so I think it would make more sense to a 
domain-specific claim like 
http://example.org/user-can-access-restricted-site. The IdP can then be 
configured to only issue cards containing this claim to users that can 
use X.509 to authenticate themselves.

Of course the second solution might be difficult, if the STS is 
controlled by some other company :). Like I said, the concept is that 
the RP trusts the IdP to do whatever it takes to authenticate the user. 
If the RP doesn't do that, it shouldn't accept identities issued by that 
IdP.

hth,
 --Chris

Thanks in advance.
            Leonardo.
 
-----Original Message-----
Sent: martedì 12 maggio 2009 15.17
To: leonardo.straniero@xxxxxxxxxxxx; Higgins (Trust Framework) Project developer discussions
Subject: Re: [higgins-dev] How specify the authentication method in the Relying Party Security Policy
 
Leonardo,
 
AFAIK you can't specify the authentication method as part of the RP
policy. The reasoning behind this is that the RP has a trust
relationship with the STS and trusts the method that the STS uses to be
"good enough". This also makes sense because the RP would have no way to
check if the STS actually used a specific method or just claims it did.
 
Of course the STS could support a set of (non-standard) claims that
assert that a certain method was used, which the RP could then require
in its policy.
 
hth,
 --Chris
 
Leonardo Straniero schrieb:
 
Hi All,
 
I am trying to understand how to specify in the Relying Party Security
Policy the authentication method (e.g. username/pwd, X509 certificate,
…) a user has to use to authenticate to the IP/STS when requesting
security tokens.
 
 
 
I think it is necessary to insert another parameter into the RP’s
*web.xml* file.
 
 
 
I saw in a security policy example a field “*Issuer*” as follows:
 
 
 
*  <param-name>Issuer</param-name>*
 
*  <param-value>shib2.internet2.edu</param-value>*
 
 
 
I know the Higgins STS provides some endpoints:
 
* *
 
*…./services/MetadataX509Token*                          (X509
Authentication)
 
*…/services/MetadataUsernameToken                *(UsernamePassword
Authentication)
 
 
 
and so on.
 
 
 
Is it possible to insert another parameter (for example a
MetadataReference parameter that identifies the STST endpoint to be
used) to specify the authentication method? Do you know if, adding a
parameter like this, CardSpace will properly manage it and select only
the cards that meet the required authentication method?
 
 
 
Any ideas?
 
Thanks in advance.
 
 
 
Best Regards.
 
* *
 
*============================*
 
*Dr. Leonardo Straniero*
 
CRS - Corporate Research
 
TXT e-Solutions SpA
 
c/o Tecnopolis N.O.
 
Strada Prov. per Casamassima Km 3
 
70010 Valenzano (BA) - Italy
 
------------------------------------------------------------------------
 
_______________________________________________
higgins-dev mailing list
 
 
 
 
 
 



_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
 

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top