Re: CORBA and GSSUP fix -- please review
The [EMAIL PROTECTED] form is also what we use in the Trifork Server/ORB... Andy Piper wrote: At 03:51 PM 2/10/2006, Aaron Mulder wrote: Just to be clear, I'm talking about GSSUP authentication (where the client sends a token containing a username and password and an encoded domain name) not one of the principal name strategies (e.g. ITT*). Jeppe, I'm not clear whether the GSS Name Form you're describing applies to the username in a username/password/domain token or the principal name in a principal name token. It would seem weird to set the username to [EMAIL PROTECTED] when the same token already contains a domain name, in effect. The format of the name passed in the username field depends on the authentication domain. If the mechanism identifier of the target domain is GSSUP, then the format of the username shall be a Scoped-Username (with name_value) as defined in Scoped- Username GSS Name Form on page 26-15 So it applies, although stripping the domain seems legal to me. andy
Re: CORBA and GSSUP fix -- please review
According to the CORBA 3.0.3 spec (and I believe the original CSIv2 spec says the same): Scoped-Username GSS Name Form The scoped-username GSS name form is defined as follows, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | [EMAIL PROTECTED] | @name_scope The '@' character shall be used to delimit name_value from name_scope. All nondelimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a scoped-username. This suggests that the right way to fix this is to make the decoder tolerant to both name and [EMAIL PROTECTED]. I don't known how the third variant - just @domain - is to be interpreted though. I'm also uncertain how an empty domain part is to be interpreted. To be on the safe side, I would suggest always encoding the full form ([EMAIL PROTECTED]) and live with the redundancy. Cheers, /Jeppe Aaron Mulder wrote: So it turns out our GSSUP token encoder set the username to [EMAIL PROTECTED] and the GSSUP token decoder did not lop off the @domain part, so Geronimo could not talk to itself using GSSUP. I changed the token encoder to just pass the username straight through -- there is a separate field in the token that holds the domain, after all, so mangling the username did not seem to make much sense. Just want to make a note of this in case someone thinks it should be changed the other way (that is, the GSSUP token encoder should send [EMAIL PROTECTED] and the GSSUP token decoder should lop off and ignore the @domain part, or compare the @domain to the domain that is sent in the other field). Thanks, Aaron P.S. Actually the GSSUP token encoder set the username to [EMAIL PROTECTED] due to an additional bug in the dynamic GSSUP configuration, so I gather no one's actually used this code before. :)
Re: Question about web app login, user principal, and authentication
Greg, I agree that there is an amount of implementation freedom wrt. when getUserPrincipal can be expected to return non-null depending on the caching strategy of the container, at least when using basic login. However, with form based login (which, in my experience, is by far the most commonly used J2EE username/password authentification mechanism), it is reasonable to assume that the user principal is cached in session state. For the record, the Trifork server caches user credentials with both basic and form based login. And although it is a valid implementation choice to reauthenticate repeatedly, I don't think that it is commonly expected that a user is immediatly kicked out of live login sessions if the sysadm changes the password (talking IT systems in general). Cheers, Jeppe Greg Wilkins wrote: Jeppe Sommer wrote: I think that it is possible to read from the servlet spec that getUserPrincipal should return the current principal for an unprotected resource. Take the following quote (servlet 2.4, section 12.10): Jeppe, The problem is that current is just not defined and it is totally implementation dependant. For FORM authentication, the current user is defined by the session. For BASIC authentication, the current user is defined by the browser invocation and and path. For CERT the current user is defined by connection and authentication credentials can be available before a protected resource has been accessed. To answer the original question - getUserPrincipal MAY return a principal for unprotected resource, but it is undefined when that is. So any application that expects unprotected resources to have a non-null principal is going to have problems if the authentication mechanism is changed. The boundaries simply cannot be defined as user previously accessed a protected resource. If the credentials are available in the request, session or connection, then they really should be checked before a principal is returned. The reason for this is that credit expires, permissions are revoked and bad users can have their accounts cancelled. Also it is possible that the credentials are present, but have never been checked within the current session. So credentials must be (re)checked at some point, again the spec does not tell us when and the natural boundaries are very much implementation dependant (request, connection, session, etc.). Thus Jetty checks the credentials whenever a request passes a declaritive authentication point or whenever a programatic authentication API is called. cheers
Re: Question about web app login, user principal, and authentication
The servlet 2.4 spec, section 12.7 states: A security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJBTM container. In other scenarios, web containers are required to allow web users that are not known to the web container or to the EJBTM container to make calls: ...then the spec goes on, describing scenarios where the user is not known to the web container - but this is not the case here, since the scenario is that the user is logged in. That is, if you are logged in (= the user is known), the web container must use your login principal in calls to the ejb container. Whether the current request is visiting a protected or unprotected resource is irrelevant. /Jeppe David Jencks wrote: i've been getting very confused by some behavior related to being logged in and authentication while working with jetspeed, and I hope someone can shed some light on what should be happening. Lets suppose you have a web app with some secured resources and some unsecured resources. If you start by accessing the unsecured resources, there is no doubt, you have not authenticated, getUserPrincipal() returns null, and you would get the DefaultSubject from ContextManager. Now if you access a secured resource, you log in, getUserPrincipal() returns a non-null principal, and you get the actual Subject from ContextManager during the call to the secured resource. Now if you go back and access an unsecured resource while still logged in, the servlet spec says you should still get the logged-in getUserPrincipal value, but ContextManager returns the DefaultSubject. So in particular calls to say an ejb will be based on the defaultSubject, not the logged in Subject, even though you are logged in. Is this correct? Or, should any access to a resource while logged in result in the ContextManager being set to the logged in subject? Spec references would be very welcome :-) thanks david jencks
