• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RemoteSSO?

 
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The code should read something like

HttpSession session = request.getSession();
session.setAttribute("password", person.getPassword());
session.setAttribute("email", person.getEmail());

Hope it helps,
Diego
[originally posted on jforum.net by andune76]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

andune76 wrote:The code should read something like

HttpSession session = request.getSession();
session.setAttribute("password", person.getPassword());
session.setAttribute("email", person.getEmail());

Hope it helps,
Diego



Ok, trying to use it directly, instead of a subclass, never know if anything is done which obscure the parameters..

[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm that did not help.. BTW.. My application of course is in another application context, is this a problem. Should I specify anything? I saw somebody mention a crosscontext thing?

The user is being picked up as annoynmus...

I am using tomcat with apache as a front proxy..
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hows it supposed to work?

I've added the attributtes in my application.. But they are not being picked up in jforum..?

this.setAttribute("password", person.getPassword());
this.setAttribute("email", person.getEmail());

Is it because they are in different contexts? Whats the normal approach to this?


regards Nino
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, you need to enable cross-context sessions or SSO in Tomcat. There is a SSOValve configuration in server.xml
[originally posted on jforum.net by andune76]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

andune76 wrote:Yes, you need to enable cross-context sessions or SSO in Tomcat. There is a SSOValve configuration in server.xml



So I just need to uncomment this:

<Valve className="org.apache.catalina.authenticator.SingleSignOn" />

and that should be it?

Or do I have to say in my web.xml that its crosscontext too somehow?


EDIT, uncommented the valve, but still no luck:/

EDIT: I modified this too:
<Context crossContext="true">


Are there any simpler ways of making this work, rebuilding jforum does not sound like a easy way..
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

andune76 wrote:It worked for me, I did not even have to modify my web.xml.

I assume you have configured sso in SystemGlobals.properties, if you have not, then that is what is troubling you.



This is what I have in systemGlobals.properties under sso:
#############################
# SSO / User authentication
#############################
# Auhentication type: use one of the following options
#
# sso: SSO based authentication. The called class will be the one
# specified by the key "sso.implementation", whic must be an implementation
# of net.jforum.sso.SSO
#
# default: Non-SSO authentication, which relies on the key
# "login.authenticator" to validate users. For more information, please see
# net.jforum.sso.LoginAuthenticator and the default implementation.
#authentication.type = default
authentication.type = sso
# The above key will be used when "authentication.type" is set to "default"
# Can be any implementation of net.jforum.sso.LoginAuthenticator
#
# For LDAP authentication, set the value to net.jforum.sso.LDAPAuthenticator. Also,
# see the LDAP section below
login.authenticator = net.jforum.sso.DefaultLoginAuthenticator

# automatic logged in when they come back to the forum
auto.login.enabled = true

# The above key will be be used then "authentication.type" is set to "sso"
# The default implementation (used here) only checks if request.getRemoteUser()
# is not null. This may be enough for many situations.
sso.implementation = net.jforum.sso.RemoteUserSSO

# Special attributes used when creating a new user
# Only if auhentication.type = sso
# The attribute name to search in the session for the password.
sso.password.attribute = password

# Same as above
sso.email.attribute = email

# The default email to use if sso.email.attribute is empty
sso.default.email = sso@user

# The default password to use if sso.password.attribute is empty
sso.default.password = sso

# Optional redirect for SSO
#
# If a value is set, the user will be redirected to the defined
# URL, using the following logic:
#
# ${sso.redirect}?returnUrl=${forum.link} + <the original JForum URL>
#
# The value MUST start with the protocol (http:// or https://)
#
sso.redirect =

Isnt it okay?
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It worked for me, I did not even have to modify my web.xml.

I assume you have configured sso in SystemGlobals.properties, if you have not, then that is what is troubling you.
[originally posted on jforum.net by andune76]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I thikn the SSO valve of tomcat allows a user to login against the tomcat security mechanism, and then it holds a user object at any request - which would pretty much work alogn with the sample RemoteSSO example that ships with jforum.

If you have your own sso implementation this is probably not sufficient - you rather have to enable the cross context entry. Another approach would be to use URL authentication for instance. This is independent from sessions or context sharing. But without url encryption it'd be high risk!
[originally posted on jforum.net by Sid]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sid wrote:I thikn the SSO valve of tomcat allows a user to login against the tomcat security mechanism, and then it holds a user object at any request - which would pretty much work alogn with the sample RemoteSSO example that ships with jforum.


So this is exactly what I am trying.. I got the idea that if there user werent created, it would be by using the values from email and username field...

Sid wrote:
If you have your own sso implementation this is probably not sufficient - you rather have to enable the cross context entry. Another approach would be to use URL authentication for instance. This is independent from sessions or context sharing. But without url encryption it'd be high risk!



As you can see from the config file, i am using the remoteSSO by jforum... I am linking from my application via an iframe to jforum...


regards Nino
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So is there anything wrong with my approach?


Could someone paste their code examples?
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure exactly what you're trying to do here. The Tomcat SSO implimentation is designed to work with Tomcat's Realm definition and the Java Servlet spec's security mechanisms.

So, besides just turning this on, you need to have a Realm implimentation defined as well, e.g. a DataSourceReam or the like. Then for each web app you are protecting, you will need to define the security constraints and other security descriptors in the WebApp's web.xml file. (See the spec for details).

Once you've done this, you should only get challenged for an id/password on the first secured webapp (in the same Realm) you hit. All this is based on the Spec level security.

At the application level, all you get from this is that you can use the request.getUserPrincipal() method to get limited info about the logged in user (basically the user name). Or you can use the request.isUserInRole(Role) method to check if the logged in user is in the specified role (as defined by the Tomcat Realm implimentation).

It also follows the HTTP spec in setting the REMOTE_USER environmental variable to the same name as the principal.

The SSO implimentation does not pass any objects back and forth beween webapps. It just uses some special cookies to identify the user principal object which is stored at the container level and shared among webapps.

In this case, JForum's RemoteUserSSO says, if the request returns a valid principal or REMOTE_USER user id, I will trust that the webserver or container has already validated that user id.

If the user id does not exist in the Jforum user tables, it will create one using the defaults in the config file for e-mail, etc. For the profile and other information to be correct for the user, the user will need to manually edit that.

E.g., you go to secured1 and login in. then you go to secured2.
[originally posted on jforum.net by monroe]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

monroe wrote:I'm not sure exactly what you're trying to do here. The Tomcat SSO implimentation is designed to work with Tomcat's Realm definition and the Java Servlet spec's security mechanisms.

So, besides just turning this on, you need to have a Realm implimentation defined as well, e.g. a DataSourceReam or the like. Then for each web app you are protecting, you will need to define the security constraints and other security descriptors in the WebApp's web.xml file. (See the spec for details).

Once you've done this, you should only get challenged for an id/password on the first secured webapp (in the same Realm) you hit. All this is based on the Spec level security.


Okay, this is not what I wanted. What I wanted was to specify a user and password in session context

monroe wrote:
At the application level, all you get from this is that you can use the request.getUserPrincipal() method to get limited info about the logged in user (basically the user name). Or you can use the request.isUserInRole(Role) method to check if the logged in user is in the specified role (as defined by the Tomcat Realm implimentation).

It also follows the HTTP spec in setting the REMOTE_USER environmental variable to the same name as the principal.

The SSO implimentation does not pass any objects back and forth beween webapps. It just uses some special cookies to identify the user principal object which is stored at the container level and shared among webapps.

In this case, JForum's RemoteUserSSO says, if the request returns a valid principal or REMOTE_USER user id, I will trust that the webserver or container has already validated that user id.

If the user id does not exist in the Jforum user tables, it will create one using the defaults in the config file for e-mail, etc. For the profile and other information to be correct for the user, the user will need to manually edit that.

E.g., you go to secured1 and login in. then you go to secured2.



So what you describe above is something like what I want.

The user goes to my application and logs in (using my own security mechanism). At some point the user decides to go to jforum. So I set two session properties, user and password and on the otherside (jforum application) checks for those two. Sees that the user are not created in the database so it goes forward and creates the user using the name and password. Could be nice to define more properties in session context, like a picture etc.

So the above scenario is possible and should work with the default remoteSSO right? So what I need is to turn off the SSO valve and just leave the cross context on right?

Another thing I have to mention is that I have apache2 infront of tomcat, but that should not mess anything up, I guess.
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you are misunderstanding the way the Specs define how a Servlet Container should act. Cross Context does not mean that there is some "shared session" object available across all webapps. This means that one web app context is able to make Requests via the dispatcher calls to another. Even there, the sessions objects are different.

If you're looking for a shared object available across multiple webapps, you'll need to do that at the container level. E.g. write your own variation of the Tomcat SSO valve. But then your app will be tied tightly to the Tomcat platform and not as portable.

You might be able to do something with a cross context call to set up a remote session prior to making a direct URL reference to it. The only thing I'm not sure of is if the session created by the cross context call will be "connected" to the end user's browser. I.e., is there a Session cookie returned to the browser so Tomcat can match the browser to the session?


[originally posted on jforum.net by monroe]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

monroe wrote:I think you are misunderstanding the way the Specs define how a Servlet Container should act. Cross Context does not mean that there is some "shared session" object available across all webapps. This means that one web app context is able to make Requests via the dispatcher calls to another. Even there, the sessions objects are different.


Okay thanks for clarifying this bit. So the http://www.jforum.net/doc/SSORemote on the wiki are meant to run somewhere within jforum?

monroe wrote:
If you're looking for a shared object available across multiple webapps, you'll need to do that at the container level. E.g. write your own variation of the Tomcat SSO valve. But then your app will be tied tightly to the Tomcat platform and not as portable.


Okay this is not what I wanted todo.. And it would probably also clutter the session somewhat..

monroe wrote:
You might be able to do something with a cross context call to set up a remote session prior to making a direct URL reference to it. The only thing I'm not sure of is if the session created by the cross context call will be "connected" to the end user's browser. I.e., is there a Session cookie returned to the browser so Tomcat can match the browser to the session?


Usually the webcontainer does one of two things:

*Sets a session cookie
*Urlrewrite (appends jsessionid)


So I guess the final thing to ask are:
Is there a way to signin a user from another java(using cookies, special urls etc) application by using the default implementations provided by Jforum?

If no, then how hard is it todo this?
I guess I would need to create my own implementation of the remote sso class and recompile jforum? Can the implementation request that a user has to be created or does that happen on default?
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nino Martinez wrote:
Usually the webcontainer does one of two things:

*Sets a session cookie
*Urlrewrite (appends jsessionid)



Yes, but with a cross context call, you call WebAppA which internally calls WebAppB. The request and response is shared, but you have two sessions involve with one URL, so which session id does jsessionid get set to? Also, some browsers might deny cookies with URLs that don't match the called URL for security reasons. Bottom line is that you'd need to determine the behaviour here.

Nino Martinez wrote:
So I guess the final thing to ask are:
Is there a way to signin a user from another java(using cookies, special urls etc) application by using the default implementations provided by Jforum?

If no, then how hard is it todo this?
I guess I would need to create my own implementation of the remote sso class and recompile jforum? Can the implementation request that a user has to be created or does that happen on default?




Unfortunately, there are no SSO standards that one can build a generic implimentation to. The closest one is to being a standard is to use HTTP authentication at the web server or container level. Which is what the RemoteUser class caters to.

However, the basic SSO interface is fairly flexible and folks have managed to implement it in lots of environments. Have you looked at the SSO section in the documents? It's not the best written but it covers the basics. There are also a lot of theads here around that.

FWIW, here's a fairly complete sample of an SSO implementation that uses Cookies. I haven't really tested this a lot since I use another method. But it should be a good starting point.





[originally posted on jforum.net by monroe]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

monroe wrote:
... code example ...



Actually the example you provided could pretty easily be genericallyfied.. If all the properties you used could be bundled in a property file instead. You could specify the MD5hash, cookie properties there instead, not having to recompile. I think that would great to bundle such a thing with jforum.

WDYT?
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry for the thread necro, but I'm working on an approach and Monroe's code snippet is very helpful. I was wondering if it would be feasible to actually retrieve the user entity during the SSO process, update fields, and then update it, allowing you to populate any field on the user object (IM, web site, location, etc).

If so, that would be pretty powerful. Using reflection, you could take a set of name/value pairs in a cookie formatted in something like YAML or JSON and look up the setter method on the User entity.

That would be pretty useful for the single sign-on approach I am looking for, where users have an account for another web app that authenticates with an archaic legacy system. I can't set up a Tomcat realm (plus I don't really want to tie the app to one container), but I can cookie any values I would need to pass any user profile data to jforum.
[originally posted on jforum.net by msernatinger]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yeah something like that would be really cool.. but I wonder if the team would support rest instead...
[originally posted on jforum.net by Nino Martinez]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Did anyone get Monroe's example to work out of the box? I've been working on it for two days and all the code seems right but every time I go to the forum I'm not logged in.
[originally posted on jforum.net by NingDynasty]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

NingDynasty wrote:Did anyone get Monroe's example to work out of the box? I've been working on it for two days and all the code seems right but every time I go to the forum I'm not logged in.



It should work heres what I have :



Although I think this solution actually creates or recreates a user each time. But im not sure.
[originally posted on jforum.net by Nino Martinez]
 
You firghten me terribly. I would like to go home now. Here, take this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic