You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Paulex Yang <pa...@gmail.com> on 2006/09/29 12:10:44 UTC
[classlib][auth]LoginContext should always invoke the LoginModules?
Hi, all
I'm not a security expert, so please correct me if I miss something. I
found some different behavior of Harmony and RI on
javax.security.auth.login.LoginContext, the testcase[1] shows the
difference.
Actually I tried to create the event sequence like below:
1. create LoginContext with some Subject
2. LoginContext.login() and return successfully
3. Modify Subject's content to make it invalid(one Principal's name
here, maybe passwd/username/servername in more general case)
4. LoginContext.login() again
In RI, the second login() invocation really tried to invoke the relative
LoginModule.login() and then failed to login with the modified Subject,
but in Harmony, both invocations succeed. I consider RI's behavior is
more reasonable.
After a rough look of LoginContext implementation, I found the cause may
be the Ln. 275
private void loginImpl() throws LoginException {
if (loggedIn) {
return;
}
....
}
Seems Harmony won't invoke the LoginModule.login() again only if the
login ever succeeds. If I comment out these lines, the test below passes
happily. Any ideas on this issue?
[1]
public class LoginContextTest extends TestCase {
private static final String VALID_NAME = "name1";
private static final String INVALID_NAME = "name2";
public void testLogin() throws Exception{
MyPrincipal pri = new MyPrincipal();
HashSet set = new HashSet();
set.add(pri);
Subject sub = new Subject(false, set, new HashSet(), new HashSet());
Configuration.setConfiguration(new MyConfig());
LoginContext context = new LoginContext("moduleName", sub);
context.login();
pri.name = INVALID_NAME;
try{
context.login();
fail("Should throw LoginException");
}catch(LoginException e){
}
}
static class MyConfig extends Configuration{
AppConfigurationEntry[] entries = new
AppConfigurationEntry[]{new
AppConfigurationEntry(MyModule.class.getName(),
LoginModuleControlFlag.REQUIRED, new HashMap())};
public AppConfigurationEntry[] getAppConfigurationEntry(String
name) {
return entries;
}
public void refresh() {
}
}
public static class MyModule implements LoginModule{
Subject sub;
public void MyModule(){
}
public boolean abort() throws LoginException {
return false;
}
public boolean commit() throws LoginException {
return true;
}
public void initialize(Subject arg0, CallbackHandler arg1,
Map<String, ?> arg2, Map<String, ?> arg3) {
sub = arg0;
}
public boolean login() throws LoginException {
Principal[] pris = sub.getPrincipals().toArray(new
Principal[0]);
return VALID_NAME.equals(pris[0].getName());
}
public boolean logout() throws LoginException {
return false;
}
}
public static class MyPrincipal implements Principal{
public String name = VALID_NAME;
public String getName() {
return name;
}
public String toString(){
return name;
}
};
}
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Stepan Mishura <st...@gmail.com>.
On 10/2/06, Tim Ellison wrote:
>
> Alex Astapchuk wrote:
> > Hi Stepan, all,
> >
> >> I think the spec. statement: "A LoginContext should not be used to
> >> authenticate more than one Subject." was taken too strict: reusing
> >> LoginContext object to get the same set of credentials seemed odd.
> >
> > The decision was mostly about resources.
> >
> > Indeed, the spec does not specify behavior of LoginContext.
> >
> > However, the spec is more or less clear in what should the
> > Login*Module*-s do in response to login/logout/etc.
> > It states 'login() saves result ...'. It does not warn with
> > anything like 'check previous state and clean up resources
> > from previous successful logins'.
> > The resource clean up is explicitly for abort() and logout().
>
> The spec might not say so explicitly, but cleaning up the resources
> before attempting another login would seem like a reasonable thing to do.
Hi Tim,
And if RI doesn't clean up resources should we do the same to be
"compatible"? :-)
I see two possible solutions here:
1) Revert the change and add javadoc comments that the second login() is
ignored if logout() is not ivoked before.
2) LoginContext calls logout() before the second login().
But both variants will be incompatible with RI (testing shows that it
doesn't invoke logout() before second login()).
Other variants?
Thanks,
Stepan.
>>> I consider RI's behavior is more reasonable.
> >
> > I would say it's more dangerous.
> > The invocation of login() on already logged LoginModule-s
> > may easily produce a resource leak.
> > Presuming the authentication is normally not a too frequent
> > task, such a leak would be really hard to discover and hunt.
>
> I don't see why we would have to suffer the leak -- if the state changes
> are made via API then we have the opportunity to fix things first.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
>
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Alex Astapchuk <al...@gmail.com>.
> Understood, some occurrences are outside our control. As you point out
> above, we shall be good citizens to the best of our ability.
Yes. LoginModule-s are out of our control.
But we can control how the LoginContext invokes them, and we can be
defensive this way.
I propose the following:
1. Leave the check that started this thread as-is:
if (already_logged) {do_nothing}
2. As this introduces a difference with RI, then document the difference
with the reason why:
the RI's behavior may introduce a resource leakage as result of
invocation LoginModule.login() on already logged modules.
3. [?] For whose who has *really strong* need in the RI's behaviour,
introduce a system property to turn it on.
Something like
-Dhy.jaas.auth.logincontext.use.unsafe.secondary.login = true/false,
false by default.
if (already_logged && !use_unsafe_secondary_login) {do_nothing}
// fall-through to process over the login()-s.
?
--
Thanks,
Alex
Tim Ellison wrote:
> Alex Astapchuk wrote:
>> Tim Ellison wrote:
>>> Alex Astapchuk wrote:
>>>> Hi Stepan, all,
>>>>
>>>>> I think the spec. statement: "A LoginContext should not be used to
>>>>> authenticate more than one Subject." was taken too strict: reusing
>>>>> LoginContext object to get the same set of credentials seemed odd.
>>>> The decision was mostly about resources.
>>>>
>>>> Indeed, the spec does not specify behavior of LoginContext.
>>>>
>>>> However, the spec is more or less clear in what should the
>>>> Login*Module*-s do in response to login/logout/etc.
>>>> It states 'login() saves result ...'. It does not warn with
>>>> anything like 'check previous state and clean up resources
>>>> from previous successful logins'.
>>>> The resource clean up is explicitly for abort() and logout().
>>> The spec might not say so explicitly, but cleaning up the resources
>>> before attempting another login would seem like a reasonable thing to do.
>> Oh yeah, with no doubt.
>> It's always good to be defensive, and careful, and accurate, and etc,
>> etc...
>> Especially when you're warned. :-)
>>
>> The JAAS tutorial has a TODO-list for LoginModule.login() [1].
>> Nothing again about 'should check and clear'.
>>
>>
>>>>>> I consider RI's behavior is more reasonable.
>>>> I would say it's more dangerous.
>>>> The invocation of login() on already logged LoginModule-s
>>>> may easily produce a resource leak.
>>>> Presuming the authentication is normally not a too frequent
>>>> task, such a leak would be really hard to discover and hunt.
>>> I don't see why we would have to suffer the leak -- if the state changes
>>> are made via API then we have the opportunity to fix things first.
>> I was talking about custom LoginModule-s, that may be plugged into an
>> app.
>>
>> Imagine a developer implementing a LoginModule. Reading through the
>> spec, s/he gets no clue s/he must free up resources in login().
>>
>> I bet most of existing LoginModule-s do not expect the second call of
>> login() after successful commit().
>>
>> I did a quick and rough googling on "implements LoginModule" and also
>> quick-checked JBoss srcs.
>> Surely, in no way this may be considered as a relevant research,
>> but from what I see - no one frees anything in login().
>>
>> So again, my point is what a call of LoginModule.login() on already
>> logged+commited LoginModule may easily introduce a resource leak when an
>> application works with a custom LoginModules.
>
> Understood, some occurrences are outside our control. As you point out
> above, we shall be good citizens to the best of our ability.
>
> Regards,
> Tim
>
>
>> [1]
>> http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#login
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Tim Ellison <t....@gmail.com>.
Alex Astapchuk wrote:
> Tim Ellison wrote:
>> Alex Astapchuk wrote:
>>> Hi Stepan, all,
>>>
>>>> I think the spec. statement: "A LoginContext should not be used to
>>>> authenticate more than one Subject." was taken too strict: reusing
>>>> LoginContext object to get the same set of credentials seemed odd.
>>> The decision was mostly about resources.
>>>
>>> Indeed, the spec does not specify behavior of LoginContext.
>>>
>>> However, the spec is more or less clear in what should the
>>> Login*Module*-s do in response to login/logout/etc.
>>> It states 'login() saves result ...'. It does not warn with
>>> anything like 'check previous state and clean up resources
>>> from previous successful logins'.
>>> The resource clean up is explicitly for abort() and logout().
>>
>> The spec might not say so explicitly, but cleaning up the resources
>> before attempting another login would seem like a reasonable thing to do.
>
> Oh yeah, with no doubt.
> It's always good to be defensive, and careful, and accurate, and etc,
> etc...
> Especially when you're warned. :-)
>
> The JAAS tutorial has a TODO-list for LoginModule.login() [1].
> Nothing again about 'should check and clear'.
>
>
>>>>> I consider RI's behavior is more reasonable.
>>> I would say it's more dangerous.
>>> The invocation of login() on already logged LoginModule-s
>>> may easily produce a resource leak.
>>> Presuming the authentication is normally not a too frequent
>>> task, such a leak would be really hard to discover and hunt.
>>
>> I don't see why we would have to suffer the leak -- if the state changes
>> are made via API then we have the opportunity to fix things first.
>
> I was talking about custom LoginModule-s, that may be plugged into an
> app.
>
> Imagine a developer implementing a LoginModule. Reading through the
> spec, s/he gets no clue s/he must free up resources in login().
>
> I bet most of existing LoginModule-s do not expect the second call of
> login() after successful commit().
>
> I did a quick and rough googling on "implements LoginModule" and also
> quick-checked JBoss srcs.
> Surely, in no way this may be considered as a relevant research,
> but from what I see - no one frees anything in login().
>
> So again, my point is what a call of LoginModule.login() on already
> logged+commited LoginModule may easily introduce a resource leak when an
> application works with a custom LoginModules.
Understood, some occurrences are outside our control. As you point out
above, we shall be good citizens to the best of our ability.
Regards,
Tim
> [1]
> http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#login
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Alex Astapchuk <al...@gmail.com>.
Tim Ellison wrote:
> Alex Astapchuk wrote:
>> Hi Stepan, all,
>>
>>> I think the spec. statement: "A LoginContext should not be used to
>>> authenticate more than one Subject." was taken too strict: reusing
>>> LoginContext object to get the same set of credentials seemed odd.
>> The decision was mostly about resources.
>>
>> Indeed, the spec does not specify behavior of LoginContext.
>>
>> However, the spec is more or less clear in what should the
>> Login*Module*-s do in response to login/logout/etc.
>> It states 'login() saves result ...'. It does not warn with
>> anything like 'check previous state and clean up resources
>> from previous successful logins'.
>> The resource clean up is explicitly for abort() and logout().
>
> The spec might not say so explicitly, but cleaning up the resources
> before attempting another login would seem like a reasonable thing to do.
Oh yeah, with no doubt.
It's always good to be defensive, and careful, and accurate, and etc,
etc...
Especially when you're warned. :-)
The JAAS tutorial has a TODO-list for LoginModule.login() [1].
Nothing again about 'should check and clear'.
>>>> I consider RI's behavior is more reasonable.
>> I would say it's more dangerous.
>> The invocation of login() on already logged LoginModule-s
>> may easily produce a resource leak.
>> Presuming the authentication is normally not a too frequent
>> task, such a leak would be really hard to discover and hunt.
>
> I don't see why we would have to suffer the leak -- if the state changes
> are made via API then we have the opportunity to fix things first.
I was talking about custom LoginModule-s, that may be plugged into an
app.
Imagine a developer implementing a LoginModule. Reading through the
spec, s/he gets no clue s/he must free up resources in login().
I bet most of existing LoginModule-s do not expect the second call of
login() after successful commit().
I did a quick and rough googling on "implements LoginModule" and also
quick-checked JBoss srcs.
Surely, in no way this may be considered as a relevant research,
but from what I see - no one frees anything in login().
So again, my point is what a call of LoginModule.login() on already
logged+commited LoginModule may easily introduce a resource leak when an
application works with a custom LoginModules.
[1]
http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#login
--
Thanks,
Alex
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Tim Ellison <t....@gmail.com>.
Alex Astapchuk wrote:
> Hi Stepan, all,
>
>> I think the spec. statement: "A LoginContext should not be used to
>> authenticate more than one Subject." was taken too strict: reusing
>> LoginContext object to get the same set of credentials seemed odd.
>
> The decision was mostly about resources.
>
> Indeed, the spec does not specify behavior of LoginContext.
>
> However, the spec is more or less clear in what should the
> Login*Module*-s do in response to login/logout/etc.
> It states 'login() saves result ...'. It does not warn with
> anything like 'check previous state and clean up resources
> from previous successful logins'.
> The resource clean up is explicitly for abort() and logout().
The spec might not say so explicitly, but cleaning up the resources
before attempting another login would seem like a reasonable thing to do.
>>> I consider RI's behavior is more reasonable.
>
> I would say it's more dangerous.
> The invocation of login() on already logged LoginModule-s
> may easily produce a resource leak.
> Presuming the authentication is normally not a too frequent
> task, such a leak would be really hard to discover and hunt.
I don't see why we would have to suffer the leak -- if the state changes
are made via API then we have the opportunity to fix things first.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Alex Astapchuk <al...@gmail.com>.
Hi Stepan, all,
> I think the spec. statement: "A LoginContext should not be used to
> authenticate more than one Subject." was taken too strict: reusing
> LoginContext object to get the same set of credentials seemed odd.
The decision was mostly about resources.
Indeed, the spec does not specify behavior of LoginContext.
However, the spec is more or less clear in what should the
Login*Module*-s do in response to login/logout/etc.
It states 'login() saves result ...'. It does not warn with
anything like 'check previous state and clean up resources
from previous successful logins'.
The resource clean up is explicitly for abort() and logout().
>> I consider RI's behavior is more reasonable.
I would say it's more dangerous.
The invocation of login() on already logged LoginModule-s
may easily produce a resource leak.
Presuming the authentication is normally not a too frequent
task, such a leak would be really hard to discover and hunt.
Just my $0.02.
--
Thanks,
Alex
Stepan Mishura wrote:
> On 9/29/06, Paulex Yang wrote:
>>
>> Hi, all
>>
>> I'm not a security expert, so please correct me if I miss something. I
>> found some different behavior of Harmony and RI on
>> javax.security.auth.login.LoginContext, the testcase[1] shows the
>> difference.
>>
>> Actually I tried to create the event sequence like below:
>> 1. create LoginContext with some Subject
>> 2. LoginContext.login() and return successfully
>> 3. Modify Subject's content to make it invalid(one Principal's name
>> here, maybe passwd/username/servername in more general case)
>
>
> Hi, Paulex
>
> LoginContext doesn't verify Subject's contents - all requred info is
> obtained with callback handler and passed to login modules. And login
> modules check whether password/username are valid or not.
>
>
> 4. LoginContext.login() again
>>
>> In RI, the second login() invocation really tried to invoke the relative
>> LoginModule.login() and then failed to login with the modified Subject,
>> but in Harmony, both invocations succeed. I consider RI's behavior is
>> more reasonable.
>>
>> After a rough look of LoginContext implementation, I found the cause may
>> be the Ln. 275
>>
>> private void loginImpl() throws LoginException {
>> if (loggedIn) {
>> return;
>> }
>> ....
>> }
>
>
> I think the spec. statement: "A LoginContext should not be used to
> authenticate more than one Subject." was taken too strict: reusing
> LoginContext object to get the same set of credentials seemed odd.
> But if RI let LoginContext object to be reusable then it makes sense doing
> the same.
>
> Thanks,
> Stepan.
>
>
> Seems Harmony won't invoke the LoginModule.login() again only if the
>> login ever succeeds. If I comment out these lines, the test below passes
>> happily. Any ideas on this issue?
>>
>>
>> [1]
>> public class LoginContextTest extends TestCase {
>> private static final String VALID_NAME = "name1";
>> private static final String INVALID_NAME = "name2";
>>
>> public void testLogin() throws Exception{
>> MyPrincipal pri = new MyPrincipal();
>> HashSet set = new HashSet();
>> set.add(pri);
>> Subject sub = new Subject(false, set, new HashSet(), new
>> HashSet());
>> Configuration.setConfiguration(new MyConfig());
>> LoginContext context = new LoginContext("moduleName", sub);
>> context.login();
>> pri.name = INVALID_NAME;
>> try{
>> context.login();
>> fail("Should throw LoginException");
>> }catch(LoginException e){
>>
>> }
>> }
>> static class MyConfig extends Configuration{
>> AppConfigurationEntry[] entries = new
>> AppConfigurationEntry[]{new
>> AppConfigurationEntry(MyModule.class.getName(),
>> LoginModuleControlFlag.REQUIRED, new HashMap())};
>> public AppConfigurationEntry[] getAppConfigurationEntry(String
>> name) {
>> return entries;
>> }
>> public void refresh() {
>> }
>> }
>> public static class MyModule implements LoginModule{
>> Subject sub;
>> public void MyModule(){
>> }
>> public boolean abort() throws LoginException {
>> return false;
>> }
>> public boolean commit() throws LoginException {
>> return true;
>> }
>> public void initialize(Subject arg0, CallbackHandler arg1,
>> Map<String, ?> arg2, Map<String, ?> arg3) {
>> sub = arg0;
>> }
>> public boolean login() throws LoginException {
>> Principal[] pris = sub.getPrincipals().toArray(new
>> Principal[0]);
>> return VALID_NAME.equals(pris[0].getName());
>> }
>> public boolean logout() throws LoginException {
>> return false;
>> }
>> }
>> public static class MyPrincipal implements Principal{
>> public String name = VALID_NAME;
>> public String getName() {
>> return name;
>> }
>> public String toString(){
>> return name;
>> }
>> };
>> }
>>
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
> ------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Stepan Mishura <st...@gmail.com>.
On 9/29/06, Paulex Yang wrote:
>
> Hi, all
>
> I'm not a security expert, so please correct me if I miss something. I
> found some different behavior of Harmony and RI on
> javax.security.auth.login.LoginContext, the testcase[1] shows the
> difference.
>
> Actually I tried to create the event sequence like below:
> 1. create LoginContext with some Subject
> 2. LoginContext.login() and return successfully
> 3. Modify Subject's content to make it invalid(one Principal's name
> here, maybe passwd/username/servername in more general case)
Hi, Paulex
LoginContext doesn't verify Subject's contents - all requred info is
obtained with callback handler and passed to login modules. And login
modules check whether password/username are valid or not.
4. LoginContext.login() again
>
> In RI, the second login() invocation really tried to invoke the relative
> LoginModule.login() and then failed to login with the modified Subject,
> but in Harmony, both invocations succeed. I consider RI's behavior is
> more reasonable.
>
> After a rough look of LoginContext implementation, I found the cause may
> be the Ln. 275
>
> private void loginImpl() throws LoginException {
> if (loggedIn) {
> return;
> }
> ....
> }
I think the spec. statement: "A LoginContext should not be used to
authenticate more than one Subject." was taken too strict: reusing
LoginContext object to get the same set of credentials seemed odd.
But if RI let LoginContext object to be reusable then it makes sense doing
the same.
Thanks,
Stepan.
Seems Harmony won't invoke the LoginModule.login() again only if the
> login ever succeeds. If I comment out these lines, the test below passes
> happily. Any ideas on this issue?
>
>
> [1]
> public class LoginContextTest extends TestCase {
> private static final String VALID_NAME = "name1";
> private static final String INVALID_NAME = "name2";
>
> public void testLogin() throws Exception{
> MyPrincipal pri = new MyPrincipal();
> HashSet set = new HashSet();
> set.add(pri);
> Subject sub = new Subject(false, set, new HashSet(), new
> HashSet());
> Configuration.setConfiguration(new MyConfig());
> LoginContext context = new LoginContext("moduleName", sub);
> context.login();
> pri.name = INVALID_NAME;
> try{
> context.login();
> fail("Should throw LoginException");
> }catch(LoginException e){
>
> }
> }
> static class MyConfig extends Configuration{
> AppConfigurationEntry[] entries = new
> AppConfigurationEntry[]{new
> AppConfigurationEntry(MyModule.class.getName(),
> LoginModuleControlFlag.REQUIRED, new HashMap())};
> public AppConfigurationEntry[] getAppConfigurationEntry(String
> name) {
> return entries;
> }
> public void refresh() {
> }
> }
> public static class MyModule implements LoginModule{
> Subject sub;
> public void MyModule(){
> }
> public boolean abort() throws LoginException {
> return false;
> }
> public boolean commit() throws LoginException {
> return true;
> }
> public void initialize(Subject arg0, CallbackHandler arg1,
> Map<String, ?> arg2, Map<String, ?> arg3) {
> sub = arg0;
> }
> public boolean login() throws LoginException {
> Principal[] pris = sub.getPrincipals().toArray(new
> Principal[0]);
> return VALID_NAME.equals(pris[0].getName());
> }
> public boolean logout() throws LoginException {
> return false;
> }
> }
> public static class MyPrincipal implements Principal{
> public String name = VALID_NAME;
> public String getName() {
> return name;
> }
> public String toString(){
> return name;
> }
> };
> }
>
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> On 10/14/06, Tim Ellison wrote:
>> Stepan Mishura wrote:
>> > So we have following suggestions:
>> >
>> > 1) leave the check and document the difference with RI
>> > 2) follow RI and put a warning
>>
>> What warning did you have in mind? And don't say j.u.logging 'cos I can
>> find out where you live you know :-)
>
> I meant adding a warning to javadoc for login() method.
Phew <g>. I think #2 is the right answer, it maintains compatibility.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Stepan Mishura <st...@gmail.com>.
On 10/14/06, Tim Ellison wrote:
>
> Stepan Mishura wrote:
> > So we have following suggestions:
> >
> > 1) leave the check and document the difference with RI
> > 2) follow RI and put a warning
>
> What warning did you have in mind? And don't say j.u.logging 'cos I can
> find out where you live you know :-)
I meant adding a warning to javadoc for login() method.
Thanks,
Stepan.
Regards,
> Tim
>
> > 3) do LogingContext.logout() before the second login()
> > 4) introduce a system property to follow RI
> >
> > Should we vote?
> >
> > Thanks,
> > Stepan.
> >
> >
> > On 9/29/06, Paulex Yang wrote:
> >>
> >> Hi, all
> >>
> >> I'm not a security expert, so please correct me if I miss something. I
> >> found some different behavior of Harmony and RI on
> >> javax.security.auth.login.LoginContext, the testcase[1] shows the
> >> difference.
> >>
> >> Actually I tried to create the event sequence like below:
> >> 1. create LoginContext with some Subject
> >> 2. LoginContext.login() and return successfully
> >> 3. Modify Subject's content to make it invalid(one Principal's name
> >> here, maybe passwd/username/servername in more general case)
> >> 4. LoginContext.login() again
> >>
> >> In RI, the second login() invocation really tried to invoke the
> relative
> >> LoginModule.login() and then failed to login with the modified Subject,
> >> but in Harmony, both invocations succeed. I consider RI's behavior is
> >> more reasonable.
> >>
> >> After a rough look of LoginContext implementation, I found the cause
> may
> >> be the Ln. 275
> >>
> >> private void loginImpl() throws LoginException {
> >> if (loggedIn) {
> >> return;
> >> }
> >> ....
> >> }
> >>
> >> Seems Harmony won't invoke the LoginModule.login() again only if the
> >> login ever succeeds. If I comment out these lines, the test below
> passes
> >> happily. Any ideas on this issue?
> >>
> >>
> >> [1]
> >> public class LoginContextTest extends TestCase {
> >> private static final String VALID_NAME = "name1";
> >> private static final String INVALID_NAME = "name2";
> >>
> >> public void testLogin() throws Exception{
> >> MyPrincipal pri = new MyPrincipal();
> >> HashSet set = new HashSet();
> >> set.add(pri);
> >> Subject sub = new Subject(false, set, new HashSet(), new
> >> HashSet());
> >> Configuration.setConfiguration(new MyConfig());
> >> LoginContext context = new LoginContext("moduleName", sub);
> >> context.login();
> >> pri.name = INVALID_NAME;
> >> try{
> >> context.login();
> >> fail("Should throw LoginException");
> >> }catch(LoginException e){
> >>
> >> }
> >> }
> >> static class MyConfig extends Configuration{
> >> AppConfigurationEntry[] entries = new
> >> AppConfigurationEntry[]{new
> >> AppConfigurationEntry(MyModule.class.getName(),
> >> LoginModuleControlFlag.REQUIRED, new HashMap())};
> >> public AppConfigurationEntry[] getAppConfigurationEntry(String
> >> name) {
> >> return entries;
> >> }
> >> public void refresh() {
> >> }
> >> }
> >> public static class MyModule implements LoginModule{
> >> Subject sub;
> >> public void MyModule(){
> >> }
> >> public boolean abort() throws LoginException {
> >> return false;
> >> }
> >> public boolean commit() throws LoginException {
> >> return true;
> >> }
> >> public void initialize(Subject arg0, CallbackHandler arg1,
> >> Map<String, ?> arg2, Map<String, ?> arg3) {
> >> sub = arg0;
> >> }
> >> public boolean login() throws LoginException {
> >> Principal[] pris = sub.getPrincipals().toArray(new
> >> Principal[0]);
> >> return VALID_NAME.equals(pris[0].getName());
> >> }
> >> public boolean logout() throws LoginException {
> >> return false;
> >> }
> >> }
> >> public static class MyPrincipal implements Principal{
> >> public String name = VALID_NAME;
> >> public String getName() {
> >> return name;
> >> }
> >> public String toString(){
> >> return name;
> >> }
> >> };
> >> }
> >>
> >>
> >>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
>
--
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> So we have following suggestions:
>
> 1) leave the check and document the difference with RI
> 2) follow RI and put a warning
What warning did you have in mind? And don't say j.u.logging 'cos I can
find out where you live you know :-)
Regards,
Tim
> 3) do LogingContext.logout() before the second login()
> 4) introduce a system property to follow RI
>
> Should we vote?
>
> Thanks,
> Stepan.
>
>
> On 9/29/06, Paulex Yang wrote:
>>
>> Hi, all
>>
>> I'm not a security expert, so please correct me if I miss something. I
>> found some different behavior of Harmony and RI on
>> javax.security.auth.login.LoginContext, the testcase[1] shows the
>> difference.
>>
>> Actually I tried to create the event sequence like below:
>> 1. create LoginContext with some Subject
>> 2. LoginContext.login() and return successfully
>> 3. Modify Subject's content to make it invalid(one Principal's name
>> here, maybe passwd/username/servername in more general case)
>> 4. LoginContext.login() again
>>
>> In RI, the second login() invocation really tried to invoke the relative
>> LoginModule.login() and then failed to login with the modified Subject,
>> but in Harmony, both invocations succeed. I consider RI's behavior is
>> more reasonable.
>>
>> After a rough look of LoginContext implementation, I found the cause may
>> be the Ln. 275
>>
>> private void loginImpl() throws LoginException {
>> if (loggedIn) {
>> return;
>> }
>> ....
>> }
>>
>> Seems Harmony won't invoke the LoginModule.login() again only if the
>> login ever succeeds. If I comment out these lines, the test below passes
>> happily. Any ideas on this issue?
>>
>>
>> [1]
>> public class LoginContextTest extends TestCase {
>> private static final String VALID_NAME = "name1";
>> private static final String INVALID_NAME = "name2";
>>
>> public void testLogin() throws Exception{
>> MyPrincipal pri = new MyPrincipal();
>> HashSet set = new HashSet();
>> set.add(pri);
>> Subject sub = new Subject(false, set, new HashSet(), new
>> HashSet());
>> Configuration.setConfiguration(new MyConfig());
>> LoginContext context = new LoginContext("moduleName", sub);
>> context.login();
>> pri.name = INVALID_NAME;
>> try{
>> context.login();
>> fail("Should throw LoginException");
>> }catch(LoginException e){
>>
>> }
>> }
>> static class MyConfig extends Configuration{
>> AppConfigurationEntry[] entries = new
>> AppConfigurationEntry[]{new
>> AppConfigurationEntry(MyModule.class.getName(),
>> LoginModuleControlFlag.REQUIRED, new HashMap())};
>> public AppConfigurationEntry[] getAppConfigurationEntry(String
>> name) {
>> return entries;
>> }
>> public void refresh() {
>> }
>> }
>> public static class MyModule implements LoginModule{
>> Subject sub;
>> public void MyModule(){
>> }
>> public boolean abort() throws LoginException {
>> return false;
>> }
>> public boolean commit() throws LoginException {
>> return true;
>> }
>> public void initialize(Subject arg0, CallbackHandler arg1,
>> Map<String, ?> arg2, Map<String, ?> arg3) {
>> sub = arg0;
>> }
>> public boolean login() throws LoginException {
>> Principal[] pris = sub.getPrincipals().toArray(new
>> Principal[0]);
>> return VALID_NAME.equals(pris[0].getName());
>> }
>> public boolean logout() throws LoginException {
>> return false;
>> }
>> }
>> public static class MyPrincipal implements Principal{
>> public String name = VALID_NAME;
>> public String getName() {
>> return name;
>> }
>> public String toString(){
>> return name;
>> }
>> };
>> }
>>
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
> ------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Stepan Mishura <st...@gmail.com>.
So we have following suggestions:
1) leave the check and document the difference with RI
2) follow RI and put a warning
3) do LogingContext.logout() before the second login()
4) introduce a system property to follow RI
Should we vote?
Thanks,
Stepan.
On 9/29/06, Paulex Yang wrote:
>
> Hi, all
>
> I'm not a security expert, so please correct me if I miss something. I
> found some different behavior of Harmony and RI on
> javax.security.auth.login.LoginContext, the testcase[1] shows the
> difference.
>
> Actually I tried to create the event sequence like below:
> 1. create LoginContext with some Subject
> 2. LoginContext.login() and return successfully
> 3. Modify Subject's content to make it invalid(one Principal's name
> here, maybe passwd/username/servername in more general case)
> 4. LoginContext.login() again
>
> In RI, the second login() invocation really tried to invoke the relative
> LoginModule.login() and then failed to login with the modified Subject,
> but in Harmony, both invocations succeed. I consider RI's behavior is
> more reasonable.
>
> After a rough look of LoginContext implementation, I found the cause may
> be the Ln. 275
>
> private void loginImpl() throws LoginException {
> if (loggedIn) {
> return;
> }
> ....
> }
>
> Seems Harmony won't invoke the LoginModule.login() again only if the
> login ever succeeds. If I comment out these lines, the test below passes
> happily. Any ideas on this issue?
>
>
> [1]
> public class LoginContextTest extends TestCase {
> private static final String VALID_NAME = "name1";
> private static final String INVALID_NAME = "name2";
>
> public void testLogin() throws Exception{
> MyPrincipal pri = new MyPrincipal();
> HashSet set = new HashSet();
> set.add(pri);
> Subject sub = new Subject(false, set, new HashSet(), new
> HashSet());
> Configuration.setConfiguration(new MyConfig());
> LoginContext context = new LoginContext("moduleName", sub);
> context.login();
> pri.name = INVALID_NAME;
> try{
> context.login();
> fail("Should throw LoginException");
> }catch(LoginException e){
>
> }
> }
> static class MyConfig extends Configuration{
> AppConfigurationEntry[] entries = new
> AppConfigurationEntry[]{new
> AppConfigurationEntry(MyModule.class.getName(),
> LoginModuleControlFlag.REQUIRED, new HashMap())};
> public AppConfigurationEntry[] getAppConfigurationEntry(String
> name) {
> return entries;
> }
> public void refresh() {
> }
> }
> public static class MyModule implements LoginModule{
> Subject sub;
> public void MyModule(){
> }
> public boolean abort() throws LoginException {
> return false;
> }
> public boolean commit() throws LoginException {
> return true;
> }
> public void initialize(Subject arg0, CallbackHandler arg1,
> Map<String, ?> arg2, Map<String, ?> arg3) {
> sub = arg0;
> }
> public boolean login() throws LoginException {
> Principal[] pris = sub.getPrincipals().toArray(new
> Principal[0]);
> return VALID_NAME.equals(pris[0].getName());
> }
> public boolean logout() throws LoginException {
> return false;
> }
> }
> public static class MyPrincipal implements Principal{
> public String name = VALID_NAME;
> public String getName() {
> return name;
> }
> public String toString(){
> return name;
> }
> };
> }
>
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Alexey Petrenko <al...@gmail.com>.
I'm not a security expert too but your solution looks reasonable for me :)
SY, Alexey
2006/9/30, Paulex Yang <pa...@gmail.com>:
> Paulex Yang wrote:
> > Hi, all
> >
> > I'm not a security expert, so please correct me if I miss something. I
> > found some different behavior of Harmony and RI on
> > javax.security.auth.login.LoginContext, the testcase[1] shows the
> > difference.
> >
> > Actually I tried to create the event sequence like below:
> > 1. create LoginContext with some Subject
> > 2. LoginContext.login() and return successfully
> > 3. Modify Subject's content to make it invalid(one Principal's name
> > here, maybe passwd/username/servername in more general case)
> > 4. LoginContext.login() again
> >
> > In RI, the second login() invocation really tried to invoke the
> > relative LoginModule.login() and then failed to login with the
> > modified Subject, but in Harmony, both invocations succeed. I consider
> > RI's behavior is more reasonable.
> >
> > After a rough look of LoginContext implementation, I found the cause
> > may be the Ln. 275
> >
> > private void loginImpl() throws LoginException {
> > if (loggedIn) {
> > return;
> > }
> > ....
> > }
> >
> > Seems Harmony won't invoke the LoginModule.login() again only if the
> > login ever succeeds. If I comment out these lines, the test below
> > passes happily. Any ideas on this issue?
> I've removed these lines at revision r451557 with regression test,
> please shout if anyone thinks the update harmful for some reason.
> >
> >
> > [1]
> > public class LoginContextTest extends TestCase {
> > private static final String VALID_NAME = "name1";
> > private static final String INVALID_NAME = "name2";
> >
> > public void testLogin() throws Exception{
> > MyPrincipal pri = new MyPrincipal();
> > HashSet set = new HashSet();
> > set.add(pri);
> > Subject sub = new Subject(false, set, new HashSet(), new
> > HashSet());
> > Configuration.setConfiguration(new MyConfig());
> > LoginContext context = new LoginContext("moduleName", sub);
> > context.login();
> > pri.name = INVALID_NAME;
> > try{
> > context.login();
> > fail("Should throw LoginException");
> > }catch(LoginException e){
> > }
> > } static class MyConfig extends Configuration{
> > AppConfigurationEntry[] entries = new
> > AppConfigurationEntry[]{new
> > AppConfigurationEntry(MyModule.class.getName(),
> > LoginModuleControlFlag.REQUIRED, new HashMap())};
> > public AppConfigurationEntry[] getAppConfigurationEntry(String
> > name) {
> > return entries;
> > }
> > public void refresh() {
> > }
> > }
> > public static class MyModule implements LoginModule{
> > Subject sub;
> > public void MyModule(){
> > }
> > public boolean abort() throws LoginException {
> > return false;
> > }
> > public boolean commit() throws LoginException {
> > return true;
> > }
> > public void initialize(Subject arg0, CallbackHandler arg1,
> > Map<String, ?> arg2, Map<String, ?> arg3) {
> > sub = arg0;
> > }
> > public boolean login() throws LoginException {
> > Principal[] pris = sub.getPrincipals().toArray(new
> > Principal[0]);
> > return VALID_NAME.equals(pris[0].getName());
> > }
> > public boolean logout() throws LoginException {
> > return false;
> > }
> > }
> > public static class MyPrincipal implements Principal{
> > public String name = VALID_NAME;
> > public String getName() {
> > return name;
> > }
> > public String toString(){
> > return name;
> > }
> > };
> > }
> >
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Stepan Mishura <st...@gmail.com>.
On 9/30/06, Paulex Yang wrote:
>
> Paulex Yang wrote:
> > Hi, all
> >
> > I'm not a security expert, so please correct me if I miss something. I
> > found some different behavior of Harmony and RI on
> > javax.security.auth.login.LoginContext, the testcase[1] shows the
> > difference.
> >
> > Actually I tried to create the event sequence like below:
> > 1. create LoginContext with some Subject
> > 2. LoginContext.login() and return successfully
> > 3. Modify Subject's content to make it invalid(one Principal's name
> > here, maybe passwd/username/servername in more general case)
> > 4. LoginContext.login() again
> >
> > In RI, the second login() invocation really tried to invoke the
> > relative LoginModule.login() and then failed to login with the
> > modified Subject, but in Harmony, both invocations succeed. I consider
> > RI's behavior is more reasonable.
> >
> > After a rough look of LoginContext implementation, I found the cause
> > may be the Ln. 275
> >
> > private void loginImpl() throws LoginException {
> > if (loggedIn) {
> > return;
> > }
> > ....
> > }
> >
> > Seems Harmony won't invoke the LoginModule.login() again only if the
> > login ever succeeds. If I comment out these lines, the test below
> > passes happily. Any ideas on this issue?
> I've removed these lines at revision r451557 with regression test,
> please shout if anyone thinks the update harmful for some reason.
I'll look into to verify if the update is harmless.
Thanks,
Stepan.
>
> >
> > [1]
> > public class LoginContextTest extends TestCase {
> > private static final String VALID_NAME = "name1";
> > private static final String INVALID_NAME = "name2";
> >
> > public void testLogin() throws Exception{
> > MyPrincipal pri = new MyPrincipal();
> > HashSet set = new HashSet();
> > set.add(pri);
> > Subject sub = new Subject(false, set, new HashSet(), new
> > HashSet());
> > Configuration.setConfiguration(new MyConfig());
> > LoginContext context = new LoginContext("moduleName", sub);
> > context.login();
> > pri.name = INVALID_NAME;
> > try{
> > context.login();
> > fail("Should throw LoginException");
> > }catch(LoginException e){
> > }
> > } static class MyConfig extends Configuration{
> > AppConfigurationEntry[] entries = new
> > AppConfigurationEntry[]{new
> > AppConfigurationEntry(MyModule.class.getName(),
> > LoginModuleControlFlag.REQUIRED, new HashMap())};
> > public AppConfigurationEntry[] getAppConfigurationEntry(String
> > name) {
> > return entries;
> > }
> > public void refresh() {
> > }
> > }
> > public static class MyModule implements LoginModule{
> > Subject sub;
> > public void MyModule(){
> > }
> > public boolean abort() throws LoginException {
> > return false;
> > }
> > public boolean commit() throws LoginException {
> > return true;
> > }
> > public void initialize(Subject arg0, CallbackHandler arg1,
> > Map<String, ?> arg2, Map<String, ?> arg3) {
> > sub = arg0;
> > }
> > public boolean login() throws LoginException {
> > Principal[] pris = sub.getPrincipals().toArray(new
> > Principal[0]);
> > return VALID_NAME.equals(pris[0].getName());
> > }
> > public boolean logout() throws LoginException {
> > return false;
> > }
> > }
> > public static class MyPrincipal implements Principal{
> > public String name = VALID_NAME;
> > public String getName() {
> > return name;
> > }
> > public String toString(){
> > return name;
> > }
> > };
> > }
> >
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Posted by Paulex Yang <pa...@gmail.com>.
Paulex Yang wrote:
> Hi, all
>
> I'm not a security expert, so please correct me if I miss something. I
> found some different behavior of Harmony and RI on
> javax.security.auth.login.LoginContext, the testcase[1] shows the
> difference.
>
> Actually I tried to create the event sequence like below:
> 1. create LoginContext with some Subject
> 2. LoginContext.login() and return successfully
> 3. Modify Subject's content to make it invalid(one Principal's name
> here, maybe passwd/username/servername in more general case)
> 4. LoginContext.login() again
>
> In RI, the second login() invocation really tried to invoke the
> relative LoginModule.login() and then failed to login with the
> modified Subject, but in Harmony, both invocations succeed. I consider
> RI's behavior is more reasonable.
>
> After a rough look of LoginContext implementation, I found the cause
> may be the Ln. 275
>
> private void loginImpl() throws LoginException {
> if (loggedIn) {
> return;
> }
> ....
> }
>
> Seems Harmony won't invoke the LoginModule.login() again only if the
> login ever succeeds. If I comment out these lines, the test below
> passes happily. Any ideas on this issue?
I've removed these lines at revision r451557 with regression test,
please shout if anyone thinks the update harmful for some reason.
>
>
> [1]
> public class LoginContextTest extends TestCase {
> private static final String VALID_NAME = "name1";
> private static final String INVALID_NAME = "name2";
>
> public void testLogin() throws Exception{
> MyPrincipal pri = new MyPrincipal();
> HashSet set = new HashSet();
> set.add(pri);
> Subject sub = new Subject(false, set, new HashSet(), new
> HashSet());
> Configuration.setConfiguration(new MyConfig());
> LoginContext context = new LoginContext("moduleName", sub);
> context.login();
> pri.name = INVALID_NAME;
> try{
> context.login();
> fail("Should throw LoginException");
> }catch(LoginException e){
> }
> } static class MyConfig extends Configuration{
> AppConfigurationEntry[] entries = new
> AppConfigurationEntry[]{new
> AppConfigurationEntry(MyModule.class.getName(),
> LoginModuleControlFlag.REQUIRED, new HashMap())};
> public AppConfigurationEntry[] getAppConfigurationEntry(String
> name) {
> return entries;
> }
> public void refresh() {
> }
> }
> public static class MyModule implements LoginModule{
> Subject sub;
> public void MyModule(){
> }
> public boolean abort() throws LoginException {
> return false;
> }
> public boolean commit() throws LoginException {
> return true;
> }
> public void initialize(Subject arg0, CallbackHandler arg1,
> Map<String, ?> arg2, Map<String, ?> arg3) {
> sub = arg0;
> }
> public boolean login() throws LoginException {
> Principal[] pris = sub.getPrincipals().toArray(new
> Principal[0]);
> return VALID_NAME.equals(pris[0].getName());
> }
> public boolean logout() throws LoginException {
> return false;
> }
> }
> public static class MyPrincipal implements Principal{
> public String name = VALID_NAME;
> public String getName() {
> return name;
> }
> public String toString(){
> return name;
> }
> };
> }
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org