----- Original Message -----
From: "Oleg Nitz" <[EMAIL PROTECTED]>
To: "jBoss" <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 11:12 AM
Subject: [jBoss-Dev] Was: [jBoss-User] Security Walkthrough/How To/Tutorial, first cut
> Hi All,
>
> Dan, Rickard, I ask you to read this message, it runs about redesign of JAAS
> security stuff, proposed by Edward Kenworthy.
> Edward, please, read the following and correct me if I retell your ideas
> incorrectly.
> First of all, I'd like to remind the current approach.
> LoginContext and Subject are created once per pair <user, security view>.
> This Subject serves solely for needs of EJB security service, other services
> shouldn't touch it.
> This makes possible to put security info to the cache and drop it at any
> moment.
> Edward proposes to create LoginContext and Subject once per user, and then to
> call a sequence of LoginModules that would add Principals, one per security
> view.
I would agree with this.
> Moreover, Edward admits that some other services may use JAAS, and they
> should use the same Subject, but own Principals.
By 'own Principals' do you mean Principals of a class that is specific to the service?
I believe that all Principals should be associated with the current LoginContext
Subject.
> Principal for EJB security should contain a set of roles as its attribute.
Here I don't agree. The roles are a subset of the Principals associated with the
Subject
executing the EJB. Neither Subject nor Principal support the notion of attributes so
you
would have to go outside of the public interfaces to implement this.
> Principal should provide the cache for the security info.
But in JAAS security info is a property of the Subject and is created by one or more
LoginModules. When a logout is issued against the current LoginContext all security
info and Principals should be removed from the Subject. I think your moving
too much behavior to Principal which is little more than an identity token. How does
the cache relate to the JAAS LoginContext, LoginModule, Subject, Refreshable,
& Destroyable entities?
> Subject should exist until shutdown of the server.
> Edward's approach looks attractive and more in spirit of JAAS then the
> current one, I confess this.
I agree that the current security should be make more consistent use of JAAS, but I
think we
need to enumerate the security use cases JBoss will support before getting to this
level
of discussion. Use case titles that I would like to see discussed include:
- Scope of a Subjects security info(Principals, credentials) in the context of the
various
units of deployment: ears, wars, ejbs. How does each level introduce the security info
revelant for that level?
- Caching and expiration of security info. What is the lifecyle of this information
and how
does it synch with the true source of the info(LDAP, JDBC, Kerberos, ...).
- Authorization beyond the simple role based model. Is there going to be support for
modifying the Java2 security policy for the current Subject. The issue is are the
AccessController.checkPermission() calls a function of the Subject as per JAAS or
are they the user independent CodeSource based view supported by Java2 < JDK1.4?
