[Openid-specs-ab] RP testing

[Roland Hedberg]

Correct !

> 26 mar 2015 kl. 20:45 skrev Hans Zandbelt <hzandbelt at pingidentity.com>:
> 
> which in its turn means that the net effect is that both of Roland's
> approaches end up being the same: "a bunch of OP configured to work in
> slightly different ways", granted that they are implemented as a single
> "multi-tenant" service, but the distinction is not visible to clients,
> right?
> 
> Hans.
> 
> On 3/25/15 4:39 PM, Justin Richer wrote:
>> I really like this approach. It makes it simple for RPs that can handle dynamic discovery (which is a very, very low bar), and it should be clear to developers/testers which test they’re trying to use at a given time.
>> 
>> It also means that each RP test will effectively have a separate issuer, which is a good way to separate things cleanly.
>> 
>>  — Justin
>> 
>> 
>>> On Mar 25, 2015, at 6:03 AM, Roland Hedberg <roland.hedberg at umu.se> wrote:
>>> 
>>> On to the next challenge :-)
>>> 
>>> In order to do RP testing you either need a bunch of OP configured to work in slightly different ways or you need an OP that can change behavior on command.
>>> 
>>> I’ve chosen the later path.
>>> I’ve constructed an OP that can be ’steered’ by crafting the URLs used in a special way.
>>> 
>>> The basic format of the path is:
>>> 
>>> /<id>/<signalg>/<encalg>/<errtype>/<claims>/<endpoint>
>>> 
>>> To start from the end:
>>> 
>>> endpoint
>>> 	is of course the different endpoints the OP presents (authorization/token/userinfo/..)
>>> claims
>>> 	is normal/aggregated/distributed
>>> errtype
>>> 	this is errors the OP should perform. This is to make certain that the RP actually checks and
>>> 	understands what it receives. So far I’ve defined these errors:
>>> 	ath     the at_hash is incorrect
>>> 	aud     ID Token with invalid aud
>>> 	ch      the c_hash is incorrect
>>> 	iat     ID Token without iat claim
>>> 	idts    the id_token signature is invalid
>>> 	issi    the id_token iss value is not the same as the provider info issuer
>>> 	isso    the provider info issuer is not the same as the discovery url
>>> 	itsub   ID Token without sub claim
>>> 	kmm     signing/encryption with a key the RP doesn't have access to
>>> 	nonce   the nonce value returned is not the same as the received
>>> 	state   the state value returned is not the same as the received
>>> encalg
>>> 	The encryption algorithms used, this is actually a tuple. The encryption alg
>>> 	and the encryption enc algorithms. The tuple are joined by a ':' so a typical
>>> 	value could be RSA1_5:A128CBC-HS256.
>>> signalg
>>> 	Specifies which algorithm that the OP should use for signing JWTs, this algorithm
>>> 	is use for all signing. So it will for instance be used both for id_token and user
>>> 	info signing. A typical value would be RSA256.
>>> id
>>> 	An identifier of the test run. This together with the IP address of the RP will
>>> 	be used to construct the filename in which the log of the test seen from the OP’s side
>>> 	will be stored.
>>> 
>>> 
>>> So if you would want to test rp-idt-iat (Reject ID Token without iat claim) the path of the URL for the
>>> authorization endpoint could be:
>>> 
>>> /rp-idt-iat/_/_/iat/normal/authorization_endpoint
>>> 
>>> It’s obvious that testing a RP that does not support dynamic provider configuration will
>>> be very laborious with the above setup so I’ve worked with the assumption that all the
>>> RPs to test can read configuration from a .well-known/openid-configuration URL and
>>> understand it.
>>> 
>>> Now, Edmund Jay asked the question whether it would be possible to make it even simpler for the
>>> RP and just request it to know the test IDs and not construct the whole path.
>>> And it can be done.
>>> 
>>> It would mean that the RP would read for example
>>> https://example.com/rp-idt-iat/.well-known/openid-configuration and the
>>> returned provider configuration would contain claims like this:
>>> 
>>> {
>>>  ”authorization_endpoint”: "https://example.com/rp-idt-iat/_/_/iat/normal/authorize",
>>>  ”token_endpoint”: ”https://example.com/rp-idt-iat/_/_/iat/normal/token”,
>>>  …
>>> }
>>> 
>>> Questions/comments ?
>>> 
>>> - Roland
>>> 
>>> "It is the consequence of humanity. We are all formed of frailty and error; let us pardon reciprocally each others’ folly - that is the first law of nature.” - Voltaire
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
> 
> --
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt at pingidentity.com | Ping Identity

- Roland

"It is the consequence of humanity. We are all formed of frailty and error; let us pardon reciprocally each others’ folly - that is the first law of nature.” - Voltaire





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150327/20c67eaa/attachment.asc>