Announcement Announcement Module
Collapse
No announcement yet.
how to set openid realm Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • how to set openid realm

    I'm getting ready to give up on using Spring Security + openid for a real web app. Basic adjustments which seem to be supported looking at the API don't work by just applying the API, are not covered in the docs, and forum and web searches provide no answers. Every adjustment I have made so far has required low-level hacking. I get the feeling that Spring Security users only use openid for sample apps. If there is some way to learn how to do these things, or if I am just missing something, please disillusion me.

    This question was posted a year ago and hasn't been answered:
    http://forum.springsource.org/showth...t=openid+realm

    I got the OpenIDAuthenticationFIlter instance from the bean factory and used setRealmMapping on it. Has no effect. ???
    Last edited by blaine; Mar 28th, 2011, 11:08 PM.

  • #2
    If there is some way to learn how to do these things, or if I am just missing something, please disillusion me.
    What things? Nobody can disillusion (or even disabuse?) you unless you explain what they are.

    Specifically:

    1. What "basic adjustments" don't work? And in what way don't they work?

    2. What "low-level hacking" was required (other than overriding a protected method, for example) ?

    3. The Javadoc for setRealmMapping explains what it is intended to do. If it "has no effect" then that is obviously a bug. But unless you explain what you set it to and what the return_to URL was in the case in question, then you are unlikely to get much useful feedback. At the very least you should post the debug output from the filter, showing the return_to and realm values being used.

    Comment


    • #3
      Originally posted by Luke Taylor View Post
      What things? Nobody can disillusion (or even disabuse?) you unless you explain what they are.Specifically:

      1. What "basic adjustments" don't work? And in what way don't they work?
      I was trying to be brief as it's off topic. I apologize, as I should have opened a separate thread to address my concern about whether openid support is complete enough to meet my needs. For the reasons described below, if I need to make considerable customizations to SS/Openid, I will probably be better off using openid4java with traditional Spring Bean config, because there is pretty much nothing in the user guide about non-openid*-declarative usage of SS/OpenID. If I do it myself, I will at least understand how it works and how to customize it.

      For some dead end issues, see recent unanswered questions in this forum about openid from "blaine".

      Another item is lack of support to pass additional HTTP params in the openid login form, since it is submitted directly to the OpenID filter. I have worked around this, but it required hacking. More generally, based on what I find in searches, interposition of registration forms and most other things are just not handled without customization outside of the provided openid* namespace.

      Another general limitation is the seeming lack of support for any app-managed authentication decisions other than looking up the user's record. Like, to implement black lists, registration schemes, constraints on providers, required OpenID attributes missing, any other criteria for getting into the site beyond Provider approval and existence of user record. The SS OpenID classes cause the authentication request to be sent to the Provider and then the AuthenticationUserDetailsService method is called to just look up the user record. According to everything I have seen (and clear implications from JavaDocs and method signatures), AuthenticationUserDetailsService.loadUserDetails() is just like UserDetailsService.loadUserDetailsByName() in that it is intended to just load user records not make other authentication decisions. Unfortunately, OpenIDAuthenticationProvider has nothing corresponding to AbstractUserDetailsAuthenticationProvider.addition alAuthenticationChecks(). We integrators are therefore forced to hack loadUserDetails for this purpose.

      Originally posted by Luke Taylor View Post
      2. What "low-level hacking" was required (other than overriding a protected method, for example) ?
      Since the openid* namespace supports very few settings and does not allow for specifying my own Provider or Filter impl. class, even overriding a protected method means that one can't use the namespace. If there is a way to replace the default OpenID Provider or Filter or invoke setters on the default ones declaratively and still use the openid* name space, please do tell. Since the user guide only describes Open id setup using the name space, and the openid sample app uses the openid* namespace, once one switches to old-fashioned bean setup they are on their own with respect to Spring Security OpenID documentation.

      In order to pass additional http params from my open id login form (for example to populate the UserDetails or to make authentication or authorization decisions) and still use the openid* name space, I resorted to using Ajax to send the field value to be written into the Session, then overrode the AuthenticationDetailsSource to move the value from the Session into the Authentication's detail so it is accessible to the AuthenticationDetailsService (which understandably does not have access to HTTP Session or Request).

      As noted above .loadUserDetails has to be hacked to make authentication decisions.

      Originally posted by Luke Taylor View Post
      3. The Javadoc for setRealmMapping explains what it is intended to do. If it "has no effect" then that is obviously a bug. But unless you explain what you set it to and what the return_to URL was in the case in question, then you are unlikely to get much useful feedback. At the very least you should post the debug output from the filter, showing the return_to and realm values being used.
      I am behind a firewall for the day so can't run this app, but I will post the details in about 10 hours from now.

      The reason I didn't post the details was, somebody may have known off the bat that this is just something that the SS OpenID implementation does not support, just like http://forum.springsource.org/showthread.php?t=105813 . Nevertheless, I should have at least turned up logging and viewed the SS logs myself by now! I got out of the habit of doing that because it's helped me very rarely-- but I admit it's definitely useful sometimes, like for the purposes you just stated.

      I can tell you now that I viewed the response from the provider to determine the return_to and realm values, then used .setRealmMapping to set a single entry from that return_to to a new realm value. When I re-ran, the realm value was unchanged. I definitely need to check these values against with SS's reports in debug logs.
      Last edited by blaine; Mar 29th, 2011, 11:09 AM. Reason: Changed to more precise class name

      Comment


      • #4
        The namespace is never going to satisfy all requirements. If you want to customize extensively, then you'll need to add the filter and provider beans. You'll find other people who have done that already. For example this thread and the linked tutorial looks like a lot of customized configuration.

        It's true that should probably also be added to the docs. But there will always be complaints about documentation for Open Source projects, no matter how much time we spend on them. Sometimes you have to nose about and find the information elsewhere, or resort to reading the source. If you want you could track down Ray and complain about why he didn't document his code properly when he worked on the OpenID provider. But you're likely to get an earful as Ray is a plain-spoken kind of guy . Even better, once you've got it working you can open a Jira and supply a doc patch. In fact, you should probably open one anyway and hopefully it will be addressed at some point.

        Regarding adding additional authentication checks to OpenIDAuthenticationProvider, my attitude would be that if it works then it is OK. I'm not a purist when it comes to implementating the code for an app. You could override the authentication method and call super or write a wrapper which delegates to the standard OpenIDAuthenticationProvider.

        Let us know what happens with the realm-mapping. You can also override the lookupRealm() method if you want to customize this further. In most cases though, it would be adequate for the realm to be constructed from the URL submitted by the user, since this is what the user assumes they are authenticating to.

        Comment


        • #5
          Tips appreciated. Thank you.

          My searches didn't hit that post showing how to get openid wired without the openid name space. Assuming that the 3.0 XML still works with 3.1, or I can figure out how to update it, that may be the key I need to make oauth do my bidding. Still several hours until I can try anything .

          Comment


          • #6
            Debug logging reports the same as my other testing, that the map I supplied is not being applied. I don't think I can be using the setter for the wrong Provider instance, because this is the only instance of that class registered in the bean factory.

            I checked the OpenIDAuthenticationFilter to see exactly where it is reporting the values, and I see that it's pretty straight forward. Maybe to do with return_to value encoding, because nothing else looks like it could prevent the map I supply from being applied. The sample in the JavaDocs shows non-encoded values being mapped, so that's what I supplied. So I should be reporting back either that I screwed something up, or a specific code bug. Probably tomorrow because I have other obligations this eve.

            Comment


            • #7
              Please post your configuration and a full stacktrace of the error you are getting (please use the code tags for both)

              Comment


              • #8
                Arrrrrrrrg! Some filesystem problem, perhaps an overheating disk, has caused my Linux workstation to halt 4 times already. I am just checking forum from laptop now and can't make any more progress for today.

                Comment


                • #9
                  I sprinkled more log statements into OpenIDAuthenticationFilter and I learned from that that two of them are being instantiated, even though my fetch for all such instances from the bean factory returns only one. That accounts. My getters must be applying to a different instance than the one doing the openid filtering.

                  Maybe my code using the bean factory is accidentally instantiating a second filter... hm... they are instantiated before I touch the bean factory... Hopefully I can nail this down before my SATA-related bug halts my workstation again.
                  Last edited by blaine; Mar 30th, 2011, 07:56 PM. Reason: added new detail

                  Comment


                  • #10
                    I find that the Spring Security sample openid app instantiates two OpenIDAuthenticationFilters, even when just restarting the app.

                    I attempted to attach the portion of my Tomcat stdout+stderr log covering the entire time period of the app restart, but it's much larger than the max attachment size of the forum. Therefore, I'll just attach thread stacks from the two instantiations. Some line numbers will be off by a few because of log statements that I have inserted.

                    I would think that two of these filters should not be instantiated, but they could serve two different purposes for all I know. Please let me know.

                    Comment


                    • #11
                      I do not think I, or anyone else, will be able to help until you post your configuration, any custom code, and a full stacktrace of the error you are getting. Please ensure to use the code tags.

                      Comment


                      • #12
                        Originally posted by rwinch View Post
                        I do not think I, or anyone else, will be able to help until you post your configuration, any custom code, and a full stacktrace of the error you are getting. Please ensure to use the code tags.
                        As I just said, this is the Spring Security openid sample application. Specifically it is the sample application built from tip of master branch about 1 week ago. I can update and rebuild in the unlikely case that there have been recent code changes. Here is the config, exactly as I pulled it from your own repository:

                        Code:
                        <?xml version="1.0" encoding="UTF-8"?>
                        
                        <!--
                          -  Namespace-based OpenID configuration
                          -->
                        
                        <b:beans xmlns="http://www.springframework.org/schema/security"
                            xmlns:b="http://www.springframework.org/schema/beans"
                            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                            xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                                                http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd">
                        
                            <http pattern="/openidlogin.jsp*" security="none" />
                            <http pattern="/images/*" security="none" />
                            <http pattern="/css/*" security="none" />
                            <http pattern="/js/*" security="none" />
                        
                            <http>
                                <intercept-url pattern="/**" access="ROLE_USER"/>
                                <logout/>
                                <openid-login login-page="/openidlogin.jsp" user-service-ref="registeringUserService"
                                        authentication-failure-url="/openidlogin.jsp?login_error=true">
                                    <attribute-exchange identifier-match="https://www.google.com/.*">
                                        <openid-attribute name="email" type="http://axschema.org/contact/email" required="true" count="1"/>
                                        <openid-attribute name="firstname" type="http://axschema.org/namePerson/first" required="true" />
                                        <openid-attribute name="lastname" type="http://axschema.org/namePerson/last" required="true" />
                                    </attribute-exchange>
                                    <attribute-exchange identifier-match=".*yahoo.com.*">
                                        <openid-attribute name="email" type="http://axschema.org/contact/email" required="true"/>
                                        <openid-attribute name="fullname" type="http://axschema.org/namePerson" required="true" />
                                    </attribute-exchange>
                                    <attribute-exchange identifier-match=".*myopenid.com.*">
                                        <openid-attribute name="email" type="http://schema.openid.net/contact/email" required="true"/>
                                        <openid-attribute name="fullname" type="http://schema.openid.net/namePerson" required="true" />
                                    </attribute-exchange>
                                </openid-login>
                                <remember-me token-repository-ref="tokenRepo"/>
                            </http>
                        
                            <b:bean id="tokenRepo"
                                    class="org.springframework.security.web.authentication.rememberme.InMemoryTokenRepositoryImpl" />
                        
                            <authentication-manager alias="authenticationManager"/>
                        
                        <!--
                            A custom UserDetailsService which will allow any user to authenticate and "register" their IDs in an internal map
                            for use if they return to the site. This is the most common usage pattern for sites which use OpenID.
                         -->
                            <b:bean id="registeringUserService" class="org.springframework.security.samples.openid.CustomUserDetailsService" />
                        
                        <!--
                            A namespace-based UserDetailsService which will reject users who are not already defined.
                            This can be used as an alternative.
                         -->
                        <!--
                            <user-service id="userService">
                                <user name="http://luke.taylor.myopenid.com/" authorities="ROLE_SUPERVISOR,ROLE_USER" />
                                <user name="http://luke.taylor.openid.cn/" authorities="ROLE_SUPERVISOR,ROLE_USER" />
                                <user name="http://raykrueger.blogspot.com/" authorities="ROLE_SUPERVISOR,ROLE_USER" />
                                <user name="http://spring.security.test.myopenid.com/" authorities="ROLE_SUPERVISOR,ROLE_USER" />
                            </user-service>
                         -->
                        </b:beans>

                        There is no error stack trace because no exception is thrown. I have attached two traces showing the precise thread stack down to both instantiations. Just open the attachments attached to my previous post.

                        Can anybody tell me whether the sample openid sample application should be instantiating two OpenIDAuthenticationFilters? I am not asking irrelevant questions. My openid realm setting is being ignored because the setter is being executed against what is likely a OpenIDAuthenticationFilter instance mistakenly being created by the Spring Security framework. This is the root cause for the problem that is the subject of this thread.
                        Last edited by blaine; Mar 31st, 2011, 08:59 AM. Reason: Pasted Spring-Security-provided config

                        Comment


                        • #13
                          Originally posted by blaine View Post
                          My openid realm setting is being ignored because the setter is being executed against what is likely a OpenIDAuthenticationFilter instance mistakenly being created by the Spring Security framework.
                          Hmm. I was initially skeptical about this, but it seems there may be a bug where the BeanDefinition is accidentally being reused. However, if you are using a BeanPostProcessor, it should still be applied to both instances. So I'm not sure why this should cause a problem...
                          Last edited by Luke Taylor; Mar 31st, 2011, 11:01 AM.

                          Comment


                          • #14
                            Issue SEC-1705.

                            Comment


                            • #15
                              Originally posted by Luke Taylor View Post
                              I think you're probably mistaken - Spring Security only registers one OpenIDAuthenticationFilter. The Spring Framework may recreate the bean for some reason, during the bean factory initialization, which would most likely explain why you see the constructor being called twice, but it will only register one instance. Whatever the reason it shouldn't affect the end result.
                              Useful feedback. Thanks.

                              In my own app, I applied the realm setter on the OpenIDAuthenticationFilter that is retreived by a getBean on the bean factory, and that is not the one that does the actual filtering (this is verified by runtime logs)-- hence lack of effect of my setter. This indicates to me that the non-functioning Filter is registered in the bean factory at least at one point in time. Since my code only retrieves the filter from the bean factory, it is impossible that I could apply my setter to the non-functional bean unless this non-functional bean is registered in the bean factory.

                              But since you say that the Filter may be recreated, I hope to avoid the issue altogether by using a more declarative approach to applying the setter. This is what I wanted to do originally, and now with the great tips I've received here recently on other threads, I hope to succeed that way now.

                              Comment

                              Working...
                              X