You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Alan D. Cabrera" <ad...@toolazydogs.com> on 2004/11/23 05:24:11 UTC
LoginDomains and automapping
I think that we should return the realm principals as well for all the same reasons that we have realm principals in the first place.
Just a heads up on the context manager. I'm correnty reworking it to clean it up and include interop.
Regards,
Alan
-----Original Message-----
From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
Sent: Mon 11/22/2004 9:26 PM
To: dev@geronimo.apache.org
Cc:
Subject: Overview of Latest Security Changes
<snip>list o great work</snip>
I also changed the login service so it returns principals generated by
server-side login modules to the client and the JaasLoginCoordinator puts
them into the Subject (not RealmPrincipals, though). This is controlled
by a new GBean attribute on the realm. Note that the J2EE containers will
still need to call ContextManager.getServerSideSubject in order to get the
RealmPrincipals -- though we may want to handle that "automagically" in
the JaasLoginCoordinator when it is actually run on the server side.
Finally, I added a simple auditing login module and some tests with two
login modules in place.
Aaron
Re: LoginDomains and automapping
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Jeff,
I think we need to work on the decision before we work on the
code. But that said, I appreciate your willingness to step up and help
with the code!
On Tue, 23 Nov 2004, Jeff Genender wrote:
> Ok, then this is my mistake. I assumed you were filling in the Subject
> with the principals, but as I re-read, I saw what you were saying,
> regarding the necessity to continue to call
> ContextManager.getServerSideSubject.
Well... There are two kinds of Principals. The LoginModules
generate Principals, and then Geronimo wraps *each one* with a
RealmPrincipal that identifies both the original Principal and the login
domain it came from (so identical Principals from separate login domains
can be distinguished). As of last night's checkin, the JaasLoginService
and JaasLoginCoordinator return all "plain" Principals but no
RealmPrincipals in the caller's Subject. This is probably OK for a client
app that wants to use the Subject for other things (though it would then
be unable to distinguish identical Principals from separate login domains
and would in fact probably only get one copy in the case of collision due
to the Principal collection being a Set). But it doesn't work for other
Geronimo components which should all use RealmPrincipals so they can make
that distinction.
Aaron
P.S. There's also one more Principal added by Geronimo, an
IdentificationPrincipal, which is not wrapped by a RealmPrincipal as there
should only ever be one per caller (not one per login domain or anything).
> I have some code that Alan and I worked on in the JaasLoginCoordinator
> that populates the subject with the principals that I *think* does the
> "automagically" you referred to in the previous email. I had the
> JaasLoginService.serverLoginModuleCommit() return a Collection of
> Principals, and then I set these principals in the Subject in the
> JaasLoginCoordinator.ServerLoginModule.commit(), very similarly as the
> ClientLoginModule. So I believe that in the same JVM, this may do as
> what you stated below. I have included the patch which we have come up
> with thus far. This is only for you guys to look at as I have not run
> the unit tests for this yet.
>
> If I am off base here, please set me straight. I am new to this code
> and am just getting my feet wet in seeing what its doing, so I may end
> up in a few dead ends.
>
> Let me know if you would like me to continue down this path, and I can
> write the unit tests for it and submit the changes.
>
> Jeff
>
> Here is the patch:
>
> Index: src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
> ===================================================================
> --- src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
> (revision 106054)
> +++ src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
> (working copy)
> @@ -210,7 +210,13 @@
> }
>
> public boolean commit() throws LoginException {
> - return service.serverLoginModuleCommit(client, index);
> + Collection c = service.serverLoginModuleCommit(client, index);
> + if (c == null)
> + return false;
> +
> + subject.getPrincipals().addAll(c);
> +
> + return true;
> }
>
> public boolean abort() throws LoginException {
> Index: src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
> ===================================================================
> --- src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
> (revision 106054)
> +++ src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
> (working copy)
> @@ -260,7 +260,7 @@
> * once for each server-side login module that was processed
> before the
> * overall authentication succeeded.
> */
> - public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
> int loginModuleIndex) throws LoginException {
> + public Collection serverLoginModuleCommit(JaasClientId
> userIdentifier, int loginModuleIndex) throws LoginException {
> JaasSecurityContext context = (JaasSecurityContext)
> activeLogins.get(userIdentifier);
> if(context == null) {
> throw new ExpiredLoginModuleException();
> @@ -270,8 +270,16 @@
> }
> JaasLoginModuleConfiguration module =
> context.getModules()[loginModuleIndex];
> boolean result = module.getLoginModule(classLoader).commit();
> +
> + if (!result)
> + return null;
> +
> context.processPrincipals();
> - return result;
> + Subject s = context.getSubject();
> + if (s == null)
> + return null;
> +
> + return s.getPrincipals();
> }
>
> /**
> Index: src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
> ===================================================================
> ---
> src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
> (revision 106054)
> +++
> src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
> (working copy)
> @@ -110,7 +110,7 @@
> * once for each server-side login module that was processed
> before the
> * overall authentication succeeded.
> */
> - public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
> int loginModuleIndex) throws LoginException;
> + public Collection serverLoginModuleCommit(JaasClientId
> userIdentifier, int loginModuleIndex) throws LoginException;
>
> /**
> * Indicates that the overall login succeeded. All login modules
> that were
>
> Aaron Mulder wrote:
> > On Mon, 22 Nov 2004, Jeff Genender wrote:
> >
> >>This is good...this should get the raw Tomcat JAASRealm to work for
> >>authorization. I just coded up a special JAASTomcatRealm that called
> >>the ContextManager.getServerSideSubject and now I can ditch it since it
> >>looks like the JaasLoginCoordinator is populating the subject.
> >
> >
> > I'm not sure you're right -- the JAASTomcatRealm should be using
> > RealmPrincipals, which are not currently returned. I need to talk this
> > over with Alan:
> >
> > Alan D. Cabrera wrote:
> >
> >>I think that we should return the realm principals as well for all the
> >>same reasons that we have realm principals in the first place.
> >
> >
> > Last time we talked you wanted to return everything except the
> > RealmPrincipals... why the change of heart?
> >
> > What if we change the JaasLoginCoordinator to load the
> > RealmPrincipals if it is used within the same JVM as the server, but not
> > if it connects over the network? That may be the best balance of "give
> > other server components what they neeed" and "don't expose Geronimo
> > security internals to clients".
> >
> > Aaron
>
Re: LoginDomains and automapping
Posted by Jeff Genender <jg...@savoirtech.com>.
Aaron,
Thanks for the reply. I took the JAASRealm code from Tomcat, and made a
Geronimo version which makes a call to ContextManager.getServerSideSubject
after obtaining the subject. I will test this when I get home tonight.
I very interested in discussing the long term approach with you as I would
like to begin thinking in this direction.
Thanks for the input, it is appreciated.
Jeff
> Jeff,
> According to a conversating I just had with Alan, the other
> container modules use a method of authorization with JACC that doesn't
> require the containers to access all the principals. Basically, they just
> give JACC the Subject containing an IdentificationPrincipal (which you
> have), and our JACC implementation looks up the proper Subject and does
> the calculations all on its side.
>
> Alan thought that maybe Tomcat does authorization differently
> (using Subject.doAs), in which case Tomcat would specifically need all the
> RealmPrincipals to be present. However, as that appears to be fairly
> slow, it's not ideal anyway.
>
> So in the short term, you should probably try to insert a call to
> ContextManager.getServerSideSubject which will get you all the
> RealmPrincipals too. If you really have trouble inserting the call in
> there, worst case, you could create a wrapper LoginModule that calls our
> JaasLoginCoordinator LoginModule and then calls
> ContextManager.getServerSideSubject and writes all the RealmPrincipals
> into the Subject that will be returned to the caller. In the long term,
> we'd like to adjust the interface between Tomcat and Geronimo to use a
> different authorization method, which will mean the RealmPrincipals are no
> longer necessary.
>
> Aaron
>
> On Tue, 23 Nov 2004, Jeff Genender wrote:
>> Ok, then this is my mistake. I assumed you were filling in the Subject
>> with the principals, but as I re-read, I saw what you were saying,
>> regarding the necessity to continue to call
>> ContextManager.getServerSideSubject.
>>
>> I have some code that Alan and I worked on in the JaasLoginCoordinator
>> that populates the subject with the principals that I *think* does the
>> "automagically" you referred to in the previous email. I had the
>> JaasLoginService.serverLoginModuleCommit() return a Collection of
>> Principals, and then I set these principals in the Subject in the
>> JaasLoginCoordinator.ServerLoginModule.commit(), very similarly as the
>> ClientLoginModule. So I believe that in the same JVM, this may do as
>> what you stated below. I have included the patch which we have come up
>> with thus far. This is only for you guys to look at as I have not run
>> the unit tests for this yet.
>>
>> If I am off base here, please set me straight. I am new to this code
>> and am just getting my feet wet in seeing what its doing, so I may end
>> up in a few dead ends.
>>
>> Let me know if you would like me to continue down this path, and I can
>> write the unit tests for it and submit the changes.
>>
>> Jeff
>>
>> Here is the patch:
>>
>> Index:
>> src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
>> ===================================================================
>> --- src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
>> (revision 106054)
>> +++ src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
>> (working copy)
>> @@ -210,7 +210,13 @@
>> }
>>
>> public boolean commit() throws LoginException {
>> - return service.serverLoginModuleCommit(client, index);
>> + Collection c = service.serverLoginModuleCommit(client,
>> index);
>> + if (c == null)
>> + return false;
>> +
>> + subject.getPrincipals().addAll(c);
>> +
>> + return true;
>> }
>>
>> public boolean abort() throws LoginException {
>> Index: src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
>> ===================================================================
>> --- src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
>> (revision 106054)
>> +++ src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
>> (working copy)
>> @@ -260,7 +260,7 @@
>> * once for each server-side login module that was processed
>> before the
>> * overall authentication succeeded.
>> */
>> - public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
>> int loginModuleIndex) throws LoginException {
>> + public Collection serverLoginModuleCommit(JaasClientId
>> userIdentifier, int loginModuleIndex) throws LoginException {
>> JaasSecurityContext context = (JaasSecurityContext)
>> activeLogins.get(userIdentifier);
>> if(context == null) {
>> throw new ExpiredLoginModuleException();
>> @@ -270,8 +270,16 @@
>> }
>> JaasLoginModuleConfiguration module =
>> context.getModules()[loginModuleIndex];
>> boolean result = module.getLoginModule(classLoader).commit();
>> +
>> + if (!result)
>> + return null;
>> +
>> context.processPrincipals();
>> - return result;
>> + Subject s = context.getSubject();
>> + if (s == null)
>> + return null;
>> +
>> + return s.getPrincipals();
>> }
>>
>> /**
>> Index:
>> src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
>> ===================================================================
>> ---
>> src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
>> (revision 106054)
>> +++
>> src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
>> (working copy)
>> @@ -110,7 +110,7 @@
>> * once for each server-side login module that was processed
>> before the
>> * overall authentication succeeded.
>> */
>> - public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
>> int loginModuleIndex) throws LoginException;
>> + public Collection serverLoginModuleCommit(JaasClientId
>> userIdentifier, int loginModuleIndex) throws LoginException;
>>
>> /**
>> * Indicates that the overall login succeeded. All login modules
>> that were
>>
>> Aaron Mulder wrote:
>> > On Mon, 22 Nov 2004, Jeff Genender wrote:
>> >
>> >>This is good...this should get the raw Tomcat JAASRealm to work for
>> >>authorization. I just coded up a special JAASTomcatRealm that called
>> >>the ContextManager.getServerSideSubject and now I can ditch it since
>> it
>> >>looks like the JaasLoginCoordinator is populating the subject.
>> >
>> >
>> > I'm not sure you're right -- the JAASTomcatRealm should be using
>> > RealmPrincipals, which are not currently returned. I need to talk
>> this
>> > over with Alan:
>> >
>> > Alan D. Cabrera wrote:
>> >
>> >>I think that we should return the realm principals as well for all the
>> >>same reasons that we have realm principals in the first place.
>> >
>> >
>> > Last time we talked you wanted to return everything except the
>> > RealmPrincipals... why the change of heart?
>> >
>> > What if we change the JaasLoginCoordinator to load the
>> > RealmPrincipals if it is used within the same JVM as the server, but
>> not
>> > if it connects over the network? That may be the best balance of
>> "give
>> > other server components what they neeed" and "don't expose Geronimo
>> > security internals to clients".
>> >
>> > Aaron
>>
>
tools.jar classpath problem
Posted by Kuato <ku...@shaw.ca>.
Hi.
How do I force geronimo to look in a specific place for tools.jar?
It's trying to load it from some old JRE I dumped long ago and
complaining it can't find it. (JAVA_HOME points to my current JDK
1.4.2._05)
Thanks
K.
Re: LoginDomains and automapping
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Jeff,
According to a conversating I just had with Alan, the other
container modules use a method of authorization with JACC that doesn't
require the containers to access all the principals. Basically, they just
give JACC the Subject containing an IdentificationPrincipal (which you
have), and our JACC implementation looks up the proper Subject and does
the calculations all on its side.
Alan thought that maybe Tomcat does authorization differently
(using Subject.doAs), in which case Tomcat would specifically need all the
RealmPrincipals to be present. However, as that appears to be fairly
slow, it's not ideal anyway.
So in the short term, you should probably try to insert a call to
ContextManager.getServerSideSubject which will get you all the
RealmPrincipals too. If you really have trouble inserting the call in
there, worst case, you could create a wrapper LoginModule that calls our
JaasLoginCoordinator LoginModule and then calls
ContextManager.getServerSideSubject and writes all the RealmPrincipals
into the Subject that will be returned to the caller. In the long term,
we'd like to adjust the interface between Tomcat and Geronimo to use a
different authorization method, which will mean the RealmPrincipals are no
longer necessary.
Aaron
On Tue, 23 Nov 2004, Jeff Genender wrote:
> Ok, then this is my mistake. I assumed you were filling in the Subject
> with the principals, but as I re-read, I saw what you were saying,
> regarding the necessity to continue to call
> ContextManager.getServerSideSubject.
>
> I have some code that Alan and I worked on in the JaasLoginCoordinator
> that populates the subject with the principals that I *think* does the
> "automagically" you referred to in the previous email. I had the
> JaasLoginService.serverLoginModuleCommit() return a Collection of
> Principals, and then I set these principals in the Subject in the
> JaasLoginCoordinator.ServerLoginModule.commit(), very similarly as the
> ClientLoginModule. So I believe that in the same JVM, this may do as
> what you stated below. I have included the patch which we have come up
> with thus far. This is only for you guys to look at as I have not run
> the unit tests for this yet.
>
> If I am off base here, please set me straight. I am new to this code
> and am just getting my feet wet in seeing what its doing, so I may end
> up in a few dead ends.
>
> Let me know if you would like me to continue down this path, and I can
> write the unit tests for it and submit the changes.
>
> Jeff
>
> Here is the patch:
>
> Index: src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
> ===================================================================
> --- src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
> (revision 106054)
> +++ src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
> (working copy)
> @@ -210,7 +210,13 @@
> }
>
> public boolean commit() throws LoginException {
> - return service.serverLoginModuleCommit(client, index);
> + Collection c = service.serverLoginModuleCommit(client, index);
> + if (c == null)
> + return false;
> +
> + subject.getPrincipals().addAll(c);
> +
> + return true;
> }
>
> public boolean abort() throws LoginException {
> Index: src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
> ===================================================================
> --- src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
> (revision 106054)
> +++ src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
> (working copy)
> @@ -260,7 +260,7 @@
> * once for each server-side login module that was processed
> before the
> * overall authentication succeeded.
> */
> - public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
> int loginModuleIndex) throws LoginException {
> + public Collection serverLoginModuleCommit(JaasClientId
> userIdentifier, int loginModuleIndex) throws LoginException {
> JaasSecurityContext context = (JaasSecurityContext)
> activeLogins.get(userIdentifier);
> if(context == null) {
> throw new ExpiredLoginModuleException();
> @@ -270,8 +270,16 @@
> }
> JaasLoginModuleConfiguration module =
> context.getModules()[loginModuleIndex];
> boolean result = module.getLoginModule(classLoader).commit();
> +
> + if (!result)
> + return null;
> +
> context.processPrincipals();
> - return result;
> + Subject s = context.getSubject();
> + if (s == null)
> + return null;
> +
> + return s.getPrincipals();
> }
>
> /**
> Index: src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
> ===================================================================
> ---
> src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
> (revision 106054)
> +++
> src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
> (working copy)
> @@ -110,7 +110,7 @@
> * once for each server-side login module that was processed
> before the
> * overall authentication succeeded.
> */
> - public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
> int loginModuleIndex) throws LoginException;
> + public Collection serverLoginModuleCommit(JaasClientId
> userIdentifier, int loginModuleIndex) throws LoginException;
>
> /**
> * Indicates that the overall login succeeded. All login modules
> that were
>
> Aaron Mulder wrote:
> > On Mon, 22 Nov 2004, Jeff Genender wrote:
> >
> >>This is good...this should get the raw Tomcat JAASRealm to work for
> >>authorization. I just coded up a special JAASTomcatRealm that called
> >>the ContextManager.getServerSideSubject and now I can ditch it since it
> >>looks like the JaasLoginCoordinator is populating the subject.
> >
> >
> > I'm not sure you're right -- the JAASTomcatRealm should be using
> > RealmPrincipals, which are not currently returned. I need to talk this
> > over with Alan:
> >
> > Alan D. Cabrera wrote:
> >
> >>I think that we should return the realm principals as well for all the
> >>same reasons that we have realm principals in the first place.
> >
> >
> > Last time we talked you wanted to return everything except the
> > RealmPrincipals... why the change of heart?
> >
> > What if we change the JaasLoginCoordinator to load the
> > RealmPrincipals if it is used within the same JVM as the server, but not
> > if it connects over the network? That may be the best balance of "give
> > other server components what they neeed" and "don't expose Geronimo
> > security internals to clients".
> >
> > Aaron
>
Re: LoginDomains and automapping
Posted by Jeff Genender <jg...@savoirtech.com>.
Ok, then this is my mistake. I assumed you were filling in the Subject
with the principals, but as I re-read, I saw what you were saying,
regarding the necessity to continue to call
ContextManager.getServerSideSubject.
I have some code that Alan and I worked on in the JaasLoginCoordinator
that populates the subject with the principals that I *think* does the
"automagically" you referred to in the previous email. I had the
JaasLoginService.serverLoginModuleCommit() return a Collection of
Principals, and then I set these principals in the Subject in the
JaasLoginCoordinator.ServerLoginModule.commit(), very similarly as the
ClientLoginModule. So I believe that in the same JVM, this may do as
what you stated below. I have included the patch which we have come up
with thus far. This is only for you guys to look at as I have not run
the unit tests for this yet.
If I am off base here, please set me straight. I am new to this code
and am just getting my feet wet in seeing what its doing, so I may end
up in a few dead ends.
Let me know if you would like me to continue down this path, and I can
write the unit tests for it and submit the changes.
Jeff
Here is the patch:
Index: src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
===================================================================
--- src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
(revision 106054)
+++ src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
(working copy)
@@ -210,7 +210,13 @@
}
public boolean commit() throws LoginException {
- return service.serverLoginModuleCommit(client, index);
+ Collection c = service.serverLoginModuleCommit(client, index);
+ if (c == null)
+ return false;
+
+ subject.getPrincipals().addAll(c);
+
+ return true;
}
public boolean abort() throws LoginException {
Index: src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
===================================================================
--- src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
(revision 106054)
+++ src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
(working copy)
@@ -260,7 +260,7 @@
* once for each server-side login module that was processed
before the
* overall authentication succeeded.
*/
- public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
int loginModuleIndex) throws LoginException {
+ public Collection serverLoginModuleCommit(JaasClientId
userIdentifier, int loginModuleIndex) throws LoginException {
JaasSecurityContext context = (JaasSecurityContext)
activeLogins.get(userIdentifier);
if(context == null) {
throw new ExpiredLoginModuleException();
@@ -270,8 +270,16 @@
}
JaasLoginModuleConfiguration module =
context.getModules()[loginModuleIndex];
boolean result = module.getLoginModule(classLoader).commit();
+
+ if (!result)
+ return null;
+
context.processPrincipals();
- return result;
+ Subject s = context.getSubject();
+ if (s == null)
+ return null;
+
+ return s.getPrincipals();
}
/**
Index: src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
===================================================================
---
src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
(revision 106054)
+++
src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
(working copy)
@@ -110,7 +110,7 @@
* once for each server-side login module that was processed
before the
* overall authentication succeeded.
*/
- public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
int loginModuleIndex) throws LoginException;
+ public Collection serverLoginModuleCommit(JaasClientId
userIdentifier, int loginModuleIndex) throws LoginException;
/**
* Indicates that the overall login succeeded. All login modules
that were
Aaron Mulder wrote:
> On Mon, 22 Nov 2004, Jeff Genender wrote:
>
>>This is good...this should get the raw Tomcat JAASRealm to work for
>>authorization. I just coded up a special JAASTomcatRealm that called
>>the ContextManager.getServerSideSubject and now I can ditch it since it
>>looks like the JaasLoginCoordinator is populating the subject.
>
>
> I'm not sure you're right -- the JAASTomcatRealm should be using
> RealmPrincipals, which are not currently returned. I need to talk this
> over with Alan:
>
> Alan D. Cabrera wrote:
>
>>I think that we should return the realm principals as well for all the
>>same reasons that we have realm principals in the first place.
>
>
> Last time we talked you wanted to return everything except the
> RealmPrincipals... why the change of heart?
>
> What if we change the JaasLoginCoordinator to load the
> RealmPrincipals if it is used within the same JVM as the server, but not
> if it connects over the network? That may be the best balance of "give
> other server components what they neeed" and "don't expose Geronimo
> security internals to clients".
>
> Aaron
Re: LoginDomains and automapping
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 22 Nov 2004, Jeff Genender wrote:
> This is good...this should get the raw Tomcat JAASRealm to work for
> authorization. I just coded up a special JAASTomcatRealm that called
> the ContextManager.getServerSideSubject and now I can ditch it since it
> looks like the JaasLoginCoordinator is populating the subject.
I'm not sure you're right -- the JAASTomcatRealm should be using
RealmPrincipals, which are not currently returned. I need to talk this
over with Alan:
Alan D. Cabrera wrote:
> I think that we should return the realm principals as well for all the
> same reasons that we have realm principals in the first place.
Last time we talked you wanted to return everything except the
RealmPrincipals... why the change of heart?
What if we change the JaasLoginCoordinator to load the
RealmPrincipals if it is used within the same JVM as the server, but not
if it connects over the network? That may be the best balance of "give
other server components what they neeed" and "don't expose Geronimo
security internals to clients".
Aaron
Re: LoginDomains and automapping
Posted by Jeff Genender <jg...@savoirtech.com>.
This is good...this should get the raw Tomcat JAASRealm to work for
authorization. I just coded up a special JAASTomcatRealm that called
the ContextManager.getServerSideSubject and now I can ditch it since it
looks like the JaasLoginCoordinator is populating the subject.
Aaron..good work...you beat us to the punch. I sent a patch (w/adc's
help - thanks) to adc that did as you stated below because I needed it
for Tomcat. I was just writing the unit tests for it ;-) Oh well...it
was a good opportunity to look at the security code!
Thanks, as this is really going to help get the JAAS working in Tomcat.
Jeff
Alan D. Cabrera wrote:
> I think that we should return the realm principals as well for all the same reasons that we have realm principals in the first place.
>
> Just a heads up on the context manager. I'm correnty reworking it to clean it up and include interop.
>
>
> Regards,
> Alan
>
> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> Sent: Mon 11/22/2004 9:26 PM
> To: dev@geronimo.apache.org
> Cc:
> Subject: Overview of Latest Security Changes
>
>
> <snip>list o great work</snip>
>
>
>
> I also changed the login service so it returns principals generated by
> server-side login modules to the client and the JaasLoginCoordinator puts
> them into the Subject (not RealmPrincipals, though). This is controlled
> by a new GBean attribute on the realm. Note that the J2EE containers will
> still need to call ContextManager.getServerSideSubject in order to get the
> RealmPrincipals -- though we may want to handle that "automagically" in
> the JaasLoginCoordinator when it is actually run on the server side.
>
> Finally, I added a simple auditing login module and some tests with two
> login modules in place.
>
> Aaron
>
>