[Openid-specs-ab] RP testing

[Hans Zandbelt]

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