login-service refactoring: authentication by assertion: saml and csi-v2

[Simon Godik <si...@godik.com>]

Here is an outline of the login-service and authentication by assertion;

There are at least 2 use cases for authentication by assertion: SAML and
CSI-V2;

SAML defines browser profile for inter-domain transfer: user agent is
transferred from the source site in one domain to the destination site in
another domain. To make long story short, destination site receives an
assertion from the source site that vouches for the caller identity;

There are 2 ways a user can log in: directly into the web-app, or by
inter-domain transfer; There are 2 issues to consider for authentication by
assertion: how to parse an assertion, and how to verify that we trust it; In
keeping with the notion that security realm is application authentication
policy, here is how security-realm is put together:

security-realm name="hello" {
	trust-rules => either embedded or a reference to the trust-managing
gbean;
	direct-login-module sufficient
	saml-art-login-module trust-ref sufficient
}

For the user that is logging in directly, direct-login-module will succeed;
for inter-domain transfer saml-art-login-module will succeed; trust rules
are either defined within security realm or by the trust-manager gbean;
Trust manager will decide if we trust assertion issuer;

CSI-V2:
I'd like csi-v2 implementation to interact with the Geronimo login service
and delegate login and trust evaluation to it;

Here is csi-v2 security-realm configuration:
Csi-v2-security-realm name = "csi-v2" {
	Trust-rules => either embedded or a reference to the trust-manager
gbean;
	Auth-token-login-module-ref required => reference to a login module
that will authenticate a user specified by the auth-token; if no auth-token
present lm.login() will return false, meaning 'ignore this login module'
	Csi-v2-login-module trust-ref required
}

First login module will try authenticating auth token if present; second
login module will examine csi-v2 assertions, evaluate trust rules, and
populate subject with delegated principals; Authenticated subject from the
auth-token-login-module is passed in the login-module shared-state;

csi-v2 callback handler has methods to set transport identity (sensitive
call, allowed for trusted code only), authentication-token, identity-token,
proxy trust rules, etc;

Then csi-v2 interceptor (trusted code) will call: csi-v2-callback-handler
cbh = new csi-v2-callback-handler(); cbh.setTransportIdentity(...) etc; 
Then: 
SubjectId subjid = login-service.login("csi-v2-security-realm-name", cbh); 
Subject subj = login-service.getSubject(subjid); etc...;

More detail on delegated principals and trust rules later.

Comments?

Simon