geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Godik" <si...@godik.com>
Subject Re: Default Security Principal & Role Mapping
Date Mon, 06 Feb 2006 21:23:45 GMT
Hi David,

>Can you elaborate  
>how we will support both forward and backward styles using the login  
>service for both?

With the csi-v2 we can have transport principal, auth-principal, and
identity token principal; Transport principal is authenticated by the
transport protocol, auth principal we must authenticate in the login service
and identity principal we should accept based on trust;

There are 2 trust models in csi-v2: forward and backward; With forward trust
we should have explicit rules saying if we trust an auth-principal (either
transport or auth token principal) to assert identity token principal; With
backward trust we should check if we trust authorization assertion that
names auth-principal as a proxy for identity principal;

Either way, login-service will authenticate auth-token and evaluate trust
(forward or backward) (with the help of the trust-manager gbean configured
into security realm) and create delegation-principals and insert them into
the subject that will be returned to the csi-v2 interceptor; 

We will map delegation principals to roles to have consistent authorization
policy;

Here is a snippet from another message I posted on this topic (login-service
re-factoring: authentication by assertion: saml and csi-v2) that has api
details:

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...;

Comments?

Simon



Mime
View raw message