Card issuing and "database" support

Coordinator
Apr 27, 2008 at 7:00 AM
So as it stands right now we don't store any information about cards issued anywhere, that's been set to one side. Now it's time to think about it.

In order to fully support card issuing, re-issuing and revocation we need to have some sort of storage somewhere, this to my mind completes the final step from a plain STS to supporting identity provider operations. So the question is where do we put this. The simple way is to extend the AuthorisationPolicyProvider again and have some operations in there (I've jiggled it about yet again recently to move things from an abstract class to an interface), but this then strongly links a backend store to the provider. This is probably acceptable, as without a backend store you can't fulfil claims anyway. The other option is yet another provider. This providers greater flexibility (in that you could share the database structure between multiple STSes, each with their own AuthorisationPolicyProvider), but it's one more separate thing to implement.

So I wanted to see if anyone had any preferences/thoughts before I switch into dictator mode and choose :)
May 1, 2008 at 6:26 PM
In our case a provider could be usefull as various STSes could require different database implementations. What is the time frame for database support? Do you anticipate the methods somewhat mirroring that of the AuthorisationPolicyProvider?

Thanks
Jeremy


blowdart wrote:
So as it stands right now we don't store any information about cards issued anywhere, that's been set to one side. Now it's time to think about it.

In order to fully support card issuing, re-issuing and revocation we need to have some sort of storage somewhere, this to my mind completes the final step from a plain STS to supporting identity provider operations. So the question is where do we put this. The simple way is to extend the AuthorisationPolicyProvider again and have some operations in there (I've jiggled it about yet again recently to move things from an abstract class to an interface), but this then strongly links a backend store to the provider. This is probably acceptable, as without a backend store you can't fulfil claims anyway. The other option is yet another provider. This providers greater flexibility (in that you could share the database structure between multiple STSes, each with their own AuthorisationPolicyProvider), but it's one more separate thing to implement.

So I wanted to see if anyone had any preferences/thoughts before I switch into dictator mode and choose :)

Coordinator
May 1, 2008 at 6:42 PM
Ah but if it's in the authorisation policy provider itself then different database implementations aren't a problem; you just keep it inside the policy. In fact in a real world scenario it's doing this anyway, from getting card ids, checking card ids, and checking claims)

But if I extract out to a provider all of its own then you could have a core database provider for card issuing (give me a new card id, log this card id as valid for this user, revoke this card id, revoke all for this user) and different authorisations.

I am leaning to just extending the authorisation policy provider right now; then separating if there's a big demand. I just need to be happy with the interface itself; still undecided about a couple of things.
May 7, 2008 at 10:50 AM
KISS :)

Just keep it in the autorisation policy provider. This needs to be fiddled with for everyone wanting to use this in production anyway, right? Like for me, I want to support WCF service to service authentication, username/password authentication and certificate authentication in addition to Identity Cards...

Morten
Coordinator
May 9, 2008 at 7:07 AM
Makes sense; I'll hopefully thrash it out over the next week or so; real life is getting in the way right now :)