Re: [tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal
On Thu, Feb 10, 2022 at 1:01 PM Rémy Maucherat wrote:
>
> On Tue, Feb 8, 2022 at 2:13 PM wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > michaelo pushed a commit to branch main
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> > new c3edf43 Add support for additional user attributes in
> > TomcatPrincipal
> > c3edf43 is described below
> >
> > commit c3edf437da20af0f11edc0ad6d893399b01e6287
> > Author: Carsten Klein
> > AuthorDate: Wed Jan 12 15:06:42 2022 +0100
> >
> > Add support for additional user attributes in TomcatPrincipal
> >
> > This closes #463
>
> -1 (veto)
The javadoc that has been agreed upon has been added (the wording can
be refined later), so the veto regarding this commit is addressed and
thus dropped.
Rémy
> Unfortunately, the more I think about this, the more it seems wrong to me.
>
> This makes the realm an object store, which is not a good idea at all,
> as it will:
> - Encourage all sorts of bad hacks and practices for users
> - Force us to gradually add more and more features to this generic
> object store feature
> - Have massive discrepancies between realms, with the users trying to
> figure out pros and cons between realms
> - Is a proprietary feature which ties up users to Tomcat
>
> More importantly: application data storage should remain the
> prerogative of the application, Tomcat should not attempt to do that.
> The only thing Tomcat should provide is a principal name, which is
> then the primary key for the third party object store. There is zero
> reason to integrate this within the realm or principal API. It also
> feels like it can never be complete or appropriate.
>
> I apologize for having to do this, after initially helping out with
> this PR, but this is one of those situations where the more I look
> about it, the worse I feel about it.
>
> Rémy
>
> > ---
> > java/org/apache/catalina/TomcatPrincipal.java | 28 +
> > .../apache/catalina/realm/GenericPrincipal.java| 46
> > ++
> > java/org/apache/catalina/realm/JNDIRealm.java | 2 +-
> > webapps/docs/changelog.xml | 5 +++
> > webapps/examples/jsp/security/protected/index.jsp | 44
> > +
> > 5 files changed, 117 insertions(+), 8 deletions(-)
> >
> > diff --git a/java/org/apache/catalina/TomcatPrincipal.java
> > b/java/org/apache/catalina/TomcatPrincipal.java
> > index 83f9035..1e3d9f6 100644
> > --- a/java/org/apache/catalina/TomcatPrincipal.java
> > +++ b/java/org/apache/catalina/TomcatPrincipal.java
> > @@ -17,6 +17,8 @@
> > package org.apache.catalina;
> >
> > import java.security.Principal;
> > +import java.util.Collections;
> > +import java.util.Enumeration;
> >
> > import org.ietf.jgss.GSSCredential;
> >
> > @@ -47,4 +49,30 @@ public interface TomcatPrincipal extends Principal {
> > * exception to LoginContext
> > */
> > void logout() throws Exception;
> > +
> > +/**
> > + * Returns the value of the named attribute as an Object,
> > or
> > + * null if no attribute of the given name exists, or if
> > + * null has been specified as the attribute's name.
> > + *
> > + * Only the servlet container may set attributes to make available
> > custom
> > + * information about a Principal or the user it represents.
> > + *
> > + * @param name a String specifying the name of the
> > attribute
> > + * @return an Object containing the value of the
> > attribute, or
> > + * null if the attribute does not exist, or if
> > + * null has been specified as the attribute's name
> > + */
> > +Object getAttribute(String name);
> > +
> > +/**
> > + * Returns an Enumeration containing the names of the
> > + * attributes available to this Principal. This method returns an empty
> > + * Enumeration if the Principal has no attributes
> > available to
> > + * it.
> > + *
> > + * @return an Enumeration of strings containing the names
> > of
> > + * the Principal's attributes
> > + */
> > +Enumeration getAttributeNames();
> > }
> > diff --git a/java/org/apache/catalina/realm/GenericPrincipal.java
> > b/java/org/apache/catalina/realm/GenericPrincipal.java
> > index 7260da4..584c104 100644
> > --- a/java/org/apache/catalina/realm/GenericPrincipal.java
> > +++ b/java/org/apache/catalina/realm/GenericPrincipal.java
> > @@ -19,7 +19,10 @@ package org.apache.catalina.realm;
> > import java.io.Serializable;
> > import java.security.Principal;
> > import java.util.Arrays;
> > +import java.util.Collections;
> > +import java.util.Enumeration;
> > import java.util.List;
> > +import java.util.Map;
> >
> > import javax.security.auth.login.LoginContext;
> >
> > @@ -120,7 +123,7 @@ public class GenericPrincipal implements
> >
Re: [tomcat] branch main updated: Add support for additional user, attributes in TomcatPrincipal
Am 2022-02-11 um 11:16 schrieb Rémy Maucherat: On Fri, Feb 11, 2022 at 10:47 AM Michael Osipov wrote: I cannot share your further explanations as well. The Realm *is* already an object store. Principal name and roles are attributes on that object, so is password. Without this possibility you have the following problems: That statement is just weird. The realm stores credentials associated with a principal name, as well as a list of roles (other names) associated with that name. That's it. An object store can store objects (like if there is a get/setAttribute that deals with Object - and that's my problem now, as it turns out ...). No, the realm stores the principal and can additionally store crdentials. You have at least two mechanism which do not verify credentials: SPNEGO and TLS mutual auth. I use both, authentication is completely decoupled from the Realm. Does this onw disqualify? The realm is always a read-only view on a store. Tomcat's intention is not to provide any read/write interface to that store. Strictly reading only. * You cannot abstract from the persistence layer in your application code, at worst you need to double code for retrieval * You double access time since you need to query the principal store again. A performance penalty in a stateless application, e.g. APIs * You maybe even not have access to the realm. Consider the identity provider gives you some form of token containing the attributes which you CANNOT retreive yourself. How to solve? You can't. I don't believe the penalty exists for a DataSource backend. Most likely for LDAP. Either way, the application is now non portable. Given that the benefit for DataSource does not seem large, this simply sounds bad in that case. For LDAP, it sounds like a tradeoff. I disagree here also. Two options: * The Realm database is decoupled form the app database, the app shall not have access to it. What now? * Consider the database is not in the same rack as the app server is. I have cases where it is 500 km away, you instantly feel that the roundtrip matters. Sometimes you simply don't have control over the environment. Yet another example: I have written code to locate the closest domain controller, if I connect to that one I have response times < 10 ms, if I connect to a DC in Munich, I suddenly have > 100 ms. Scale here. No one is aiming here for an ORM layer. One of my points is that this is really far from obvious in the API, so it needs a round of javadoc tightening up. Please do so. M
Re: Re: [tomcat] branch main updated: Add support for additional user, attributes in TomcatPrincipal
On Fri, Feb 11, 2022 at 10:47 AM Michael Osipov wrote: > > Rémy, > > really, I don't understand your work attitude. Carsten contacted us on > the mailing list before providing the PR. Then he provided the PR. It > was open for EIGHT months. We discussed this in and out, with you and > Mark. Everyone expressed the conditions he is willing to accept the PR. > I have even asked Carsten to break up the PR to please you. The purpose > of RTC/PR is to express your opinion BEFORE it gets merged to avoid > post-mortem discussions like this. You expressed your conditions and now > you object? This is absolutely not fair and unprofessional. I apologized for this already. I am really sorry about this but background thinking led to different conclusions over time. > I cannot share your further explanations as well. The Realm *is* already > an object store. Principal name and roles are attributes on that object, > so is password. Without this possibility you have the following problems: That statement is just weird. The realm stores credentials associated with a principal name, as well as a list of roles (other names) associated with that name. That's it. An object store can store objects (like if there is a get/setAttribute that deals with Object - and that's my problem now, as it turns out ...). > * You cannot abstract from the persistence layer in your application > code, at worst you need to double code for retrieval > * You double access time since you need to query the principal store > again. A performance penalty in a stateless application, e.g. APIs > * You maybe even not have access to the realm. Consider the identity > provider gives you some form of token containing the attributes which > you CANNOT retreive yourself. How to solve? You can't. I don't believe the penalty exists for a DataSource backend. Most likely for LDAP. Either way, the application is now non portable. Given that the benefit for DataSource does not seem large, this simply sounds bad in that case. For LDAP, it sounds like a tradeoff. > No one is aiming here for an ORM layer. One of my points is that this is really far from obvious in the API, so it needs a round of javadoc tightening up. Rémy > > > Mark, > > you have even assisted on how to backport to previous versions and > object somewhat as well? I don't understand that. > > > From my PoV Carsten did everything we requested over a very long period > of time. > > M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Re: [tomcat] branch main updated: Add support for additional user, attributes in TomcatPrincipal
Rémy, really, I don't understand your work attitude. Carsten contacted us on the mailing list before providing the PR. Then he provided the PR. It was open for EIGHT months. We discussed this in and out, with you and Mark. Everyone expressed the conditions he is willing to accept the PR. I have even asked Carsten to break up the PR to please you. The purpose of RTC/PR is to express your opinion BEFORE it gets merged to avoid post-mortem discussions like this. You expressed your conditions and now you object? This is absolutely not fair and unprofessional. I cannot share your further explanations as well. The Realm *is* already an object store. Principal name and roles are attributes on that object, so is password. Without this possibility you have the following problems: * You cannot abstract from the persistence layer in your application code, at worst you need to double code for retrieval * You double access time since you need to query the principal store again. A performance penalty in a stateless application, e.g. APIs * You maybe even not have access to the realm. Consider the identity provider gives you some form of token containing the attributes which you CANNOT retreive yourself. How to solve? You can't. No one is aiming here for an ORM layer. Mark, you have even assisted on how to backport to previous versions and object somewhat as well? I don't understand that. From my PoV Carsten did everything we requested over a very long period of time. M
Re: [tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal
On Thu, Feb 10, 2022 at 2:48 PM Mark Thomas wrote: > > On 10/02/2022 12:01, Rémy Maucherat wrote: > > On Tue, Feb 8, 2022 at 2:13 PM wrote: > >> > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> michaelo pushed a commit to branch main > >> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >> > >> > >> The following commit(s) were added to refs/heads/main by this push: > >> new c3edf43 Add support for additional user attributes in > >> TomcatPrincipal > >> c3edf43 is described below > >> > >> commit c3edf437da20af0f11edc0ad6d893399b01e6287 > >> Author: Carsten Klein > >> AuthorDate: Wed Jan 12 15:06:42 2022 +0100 > >> > >> Add support for additional user attributes in TomcatPrincipal > >> > >> This closes #463 > > > > -1 (veto) > > > > Unfortunately, the more I think about this, the more it seems wrong to me. > > ACK. I won't tag until this has been reverted or you retract the veto. > > I will note that if I get to the point where I am ready to tag and this > is the only issue remaining to resolve I will revert the change prior to > the tag - although I'd prefer that michaelo did that before then. > > > This makes the realm an object store, which is not a good idea at all, > > as it will: > > - Encourage all sorts of bad hacks and practices for users > > - Force us to gradually add more and more features to this generic > > object store feature > > - Have massive discrepancies between realms, with the users trying to > > figure out pros and cons between realms > > - Is a proprietary feature which ties up users to Tomcat > > Just trying to understand the concern at this point. > > You think the risk is that developers will push data in the Realm and > then access from the authenticated principal? This will seem convenient. If building an e-commerce thingie, you could imagine storing payment info, all misc info, shopping cart. The only thing preventing this is that there is no setAttribute(String name, Object value), but what if someone comes along with a PR later ? Is that a "no" then ? Why would this be more a "no" than for this one ? This is clearly my concern now [following lingering thoughts about how this could be (ab)used]. Again I would like to apologize for taking so long until reaching this position, I know this wastes a lot of time ... My wider concerns were initially triggered when there was suddenly some intent to add the feature to the UserDatabase (which is a R/W database for users, so there the feature clearly becomes general object storage - even though the PR only contained a mock impl). > > More importantly: application data storage should remain the > > prerogative of the application, Tomcat should not attempt to do that. > > The only thing Tomcat should provide is a principal name, which is > > then the primary key for the third party object store. There is zero > > reason to integrate this within the realm or principal API. It also > > feels like it can never be complete or appropriate. > > Looking at the proposed change for the DataSourceRealm I can see it has > clearly defined limits. I can see how we might get requests to push back > those limits in the future. > > I have a general concern / unease that doing this in an application > specific manner would be relatively easy but doing it generically could > get complex. > > > I apologize for having to do this, after initially helping out with > > this PR, but this is one of those situations where the more I look > > about it, the worse I feel about it. > > I do recognise the use case of wanting to expose data that is already in > the Realm to the application. Yes, that was what I was thinking about too. But then it still encourages putting more stuff in the realm backend (since now you can, you probably know how it works by now). The use case in the PR is the DataSourceRealm (not the LDAP one), so let's assume it is a JDBC thing. Retrieving the data from another data source connecting to the same backend in the application might (supposedly) be less efficient (but if you pull a lot of data from the DB, it will suddenly be impossible to tell the difference), but is portable and you could store things properly (and more importantly avoid asking us to add code to automagically map to Java collections ... that's just for starters obviously). > I wonder whether this is a case where we can just provide some hooks > and, if the developer chooses to (ab)use them, that is up to them. > > I'm thinking something like a getUserAttributes() method on Realm that > returns null by default. If an application wants to populate additional > attributes, then it needs to provide a custom realm that overrides that > method. The issue with this approach is it requires a custom realm. > > Given your concerns, backing this out while we discuss it some more > seems like the right approach to me. If there's firm consensus that this feature is final for there, then I could drop the veto
Re: [tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal
On 10/02/2022 12:01, Rémy Maucherat wrote: On Tue, Feb 8, 2022 at 2:13 PM wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/main by this push: new c3edf43 Add support for additional user attributes in TomcatPrincipal c3edf43 is described below commit c3edf437da20af0f11edc0ad6d893399b01e6287 Author: Carsten Klein AuthorDate: Wed Jan 12 15:06:42 2022 +0100 Add support for additional user attributes in TomcatPrincipal This closes #463 -1 (veto) Unfortunately, the more I think about this, the more it seems wrong to me. ACK. I won't tag until this has been reverted or you retract the veto. I will note that if I get to the point where I am ready to tag and this is the only issue remaining to resolve I will revert the change prior to the tag - although I'd prefer that michaelo did that before then. This makes the realm an object store, which is not a good idea at all, as it will: - Encourage all sorts of bad hacks and practices for users - Force us to gradually add more and more features to this generic object store feature - Have massive discrepancies between realms, with the users trying to figure out pros and cons between realms - Is a proprietary feature which ties up users to Tomcat Just trying to understand the concern at this point. You think the risk is that developers will push data in the Realm and then access from the authenticated principal? More importantly: application data storage should remain the prerogative of the application, Tomcat should not attempt to do that. The only thing Tomcat should provide is a principal name, which is then the primary key for the third party object store. There is zero reason to integrate this within the realm or principal API. It also feels like it can never be complete or appropriate. Looking at the proposed change for the DataSourceRealm I can see it has clearly defined limits. I can see how we might get requests to push back those limits in the future. I have a general concern / unease that doing this in an application specific manner would be relatively easy but doing it generically could get complex. I apologize for having to do this, after initially helping out with this PR, but this is one of those situations where the more I look about it, the worse I feel about it. I do recognise the use case of wanting to expose data that is already in the Realm to the application. I wonder whether this is a case where we can just provide some hooks and, if the developer chooses to (ab)use them, that is up to them. I'm thinking something like a getUserAttributes() method on Realm that returns null by default. If an application wants to populate additional attributes, then it needs to provide a custom realm that overrides that method. The issue with this approach is it requires a custom realm. Given your concerns, backing this out while we discuss it some more seems like the right approach to me. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal
On Tue, Feb 8, 2022 at 2:13 PM wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> michaelo pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new c3edf43 Add support for additional user attributes in
> TomcatPrincipal
> c3edf43 is described below
>
> commit c3edf437da20af0f11edc0ad6d893399b01e6287
> Author: Carsten Klein
> AuthorDate: Wed Jan 12 15:06:42 2022 +0100
>
> Add support for additional user attributes in TomcatPrincipal
>
> This closes #463
-1 (veto)
Unfortunately, the more I think about this, the more it seems wrong to me.
This makes the realm an object store, which is not a good idea at all,
as it will:
- Encourage all sorts of bad hacks and practices for users
- Force us to gradually add more and more features to this generic
object store feature
- Have massive discrepancies between realms, with the users trying to
figure out pros and cons between realms
- Is a proprietary feature which ties up users to Tomcat
More importantly: application data storage should remain the
prerogative of the application, Tomcat should not attempt to do that.
The only thing Tomcat should provide is a principal name, which is
then the primary key for the third party object store. There is zero
reason to integrate this within the realm or principal API. It also
feels like it can never be complete or appropriate.
I apologize for having to do this, after initially helping out with
this PR, but this is one of those situations where the more I look
about it, the worse I feel about it.
Rémy
> ---
> java/org/apache/catalina/TomcatPrincipal.java | 28 +
> .../apache/catalina/realm/GenericPrincipal.java| 46
> ++
> java/org/apache/catalina/realm/JNDIRealm.java | 2 +-
> webapps/docs/changelog.xml | 5 +++
> webapps/examples/jsp/security/protected/index.jsp | 44 +
> 5 files changed, 117 insertions(+), 8 deletions(-)
>
> diff --git a/java/org/apache/catalina/TomcatPrincipal.java
> b/java/org/apache/catalina/TomcatPrincipal.java
> index 83f9035..1e3d9f6 100644
> --- a/java/org/apache/catalina/TomcatPrincipal.java
> +++ b/java/org/apache/catalina/TomcatPrincipal.java
> @@ -17,6 +17,8 @@
> package org.apache.catalina;
>
> import java.security.Principal;
> +import java.util.Collections;
> +import java.util.Enumeration;
>
> import org.ietf.jgss.GSSCredential;
>
> @@ -47,4 +49,30 @@ public interface TomcatPrincipal extends Principal {
> * exception to LoginContext
> */
> void logout() throws Exception;
> +
> +/**
> + * Returns the value of the named attribute as an Object, or
> + * null if no attribute of the given name exists, or if
> + * null has been specified as the attribute's name.
> + *
> + * Only the servlet container may set attributes to make available custom
> + * information about a Principal or the user it represents.
> + *
> + * @param name a String specifying the name of the attribute
> + * @return an Object containing the value of the attribute,
> or
> + * null if the attribute does not exist, or if
> + * null has been specified as the attribute's name
> + */
> +Object getAttribute(String name);
> +
> +/**
> + * Returns an Enumeration containing the names of the
> + * attributes available to this Principal. This method returns an empty
> + * Enumeration if the Principal has no attributes available
> to
> + * it.
> + *
> + * @return an Enumeration of strings containing the names of
> + * the Principal's attributes
> + */
> +Enumeration getAttributeNames();
> }
> diff --git a/java/org/apache/catalina/realm/GenericPrincipal.java
> b/java/org/apache/catalina/realm/GenericPrincipal.java
> index 7260da4..584c104 100644
> --- a/java/org/apache/catalina/realm/GenericPrincipal.java
> +++ b/java/org/apache/catalina/realm/GenericPrincipal.java
> @@ -19,7 +19,10 @@ package org.apache.catalina.realm;
> import java.io.Serializable;
> import java.security.Principal;
> import java.util.Arrays;
> +import java.util.Collections;
> +import java.util.Enumeration;
> import java.util.List;
> +import java.util.Map;
>
> import javax.security.auth.login.LoginContext;
>
> @@ -120,7 +123,7 @@ public class GenericPrincipal implements TomcatPrincipal,
> Serializable {
> */
> public GenericPrincipal(String name, List roles,
> Principal userPrincipal, LoginContext loginContext) {
> -this(name, roles, userPrincipal, loginContext, null);
> +this(name, roles, userPrincipal, loginContext, null, null);
> }
>
> /**
> @@ -140,7 +143,7 @@ public class GenericPrincipal implements TomcatPrincipal,
> Serializable {
> @Deprecated
> public GenericPrincipal(String
[tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal
This is an automated email from the ASF dual-hosted git repository.
michaelo pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new c3edf43 Add support for additional user attributes in TomcatPrincipal
c3edf43 is described below
commit c3edf437da20af0f11edc0ad6d893399b01e6287
Author: Carsten Klein
AuthorDate: Wed Jan 12 15:06:42 2022 +0100
Add support for additional user attributes in TomcatPrincipal
This closes #463
---
java/org/apache/catalina/TomcatPrincipal.java | 28 +
.../apache/catalina/realm/GenericPrincipal.java| 46 ++
java/org/apache/catalina/realm/JNDIRealm.java | 2 +-
webapps/docs/changelog.xml | 5 +++
webapps/examples/jsp/security/protected/index.jsp | 44 +
5 files changed, 117 insertions(+), 8 deletions(-)
diff --git a/java/org/apache/catalina/TomcatPrincipal.java
b/java/org/apache/catalina/TomcatPrincipal.java
index 83f9035..1e3d9f6 100644
--- a/java/org/apache/catalina/TomcatPrincipal.java
+++ b/java/org/apache/catalina/TomcatPrincipal.java
@@ -17,6 +17,8 @@
package org.apache.catalina;
import java.security.Principal;
+import java.util.Collections;
+import java.util.Enumeration;
import org.ietf.jgss.GSSCredential;
@@ -47,4 +49,30 @@ public interface TomcatPrincipal extends Principal {
* exception to LoginContext
*/
void logout() throws Exception;
+
+/**
+ * Returns the value of the named attribute as an Object, or
+ * null if no attribute of the given name exists, or if
+ * null has been specified as the attribute's name.
+ *
+ * Only the servlet container may set attributes to make available custom
+ * information about a Principal or the user it represents.
+ *
+ * @param name a String specifying the name of the attribute
+ * @return an Object containing the value of the attribute, or
+ * null if the attribute does not exist, or if
+ * null has been specified as the attribute's name
+ */
+Object getAttribute(String name);
+
+/**
+ * Returns an Enumeration containing the names of the
+ * attributes available to this Principal. This method returns an empty
+ * Enumeration if the Principal has no attributes available to
+ * it.
+ *
+ * @return an Enumeration of strings containing the names of
+ * the Principal's attributes
+ */
+Enumeration getAttributeNames();
}
diff --git a/java/org/apache/catalina/realm/GenericPrincipal.java
b/java/org/apache/catalina/realm/GenericPrincipal.java
index 7260da4..584c104 100644
--- a/java/org/apache/catalina/realm/GenericPrincipal.java
+++ b/java/org/apache/catalina/realm/GenericPrincipal.java
@@ -19,7 +19,10 @@ package org.apache.catalina.realm;
import java.io.Serializable;
import java.security.Principal;
import java.util.Arrays;
+import java.util.Collections;
+import java.util.Enumeration;
import java.util.List;
+import java.util.Map;
import javax.security.auth.login.LoginContext;
@@ -120,7 +123,7 @@ public class GenericPrincipal implements TomcatPrincipal,
Serializable {
*/
public GenericPrincipal(String name, List roles,
Principal userPrincipal, LoginContext loginContext) {
-this(name, roles, userPrincipal, loginContext, null);
+this(name, roles, userPrincipal, loginContext, null, null);
}
/**
@@ -140,7 +143,7 @@ public class GenericPrincipal implements TomcatPrincipal,
Serializable {
@Deprecated
public GenericPrincipal(String name, String password, List roles,
Principal userPrincipal, LoginContext loginContext) {
-this(name, roles, userPrincipal, loginContext, null);
+this(name, roles, userPrincipal, loginContext, null, null);
}
/**
@@ -154,10 +157,12 @@ public class GenericPrincipal implements TomcatPrincipal,
Serializable {
* @param loginContext - If provided, this will be used to log out the
user
*at the appropriate time
* @param gssCredential - If provided, the user's delegated credentials
+ * @param attributes - If provided, additional attributes associated with
+ *this Principal
*/
public GenericPrincipal(String name, List roles,
Principal userPrincipal, LoginContext loginContext,
-GSSCredential gssCredential) {
+GSSCredential gssCredential, Map attributes) {
super();
this.name = name;
this.userPrincipal = userPrincipal;
@@ -171,6 +176,7 @@ public class GenericPrincipal implements TomcatPrincipal,
Serializable {
}
this.loginContext = loginContext;
this.gssCredential = gssCredential;
+this.attributes = attributes != null ?
Collections.unmodifiableMap(attributes) : null;
}
@@
