1 2 Previous Next 20 Replies Latest reply on Mar 24, 2011 11:23 AM by matthew.hayes

    SAML Attributes Discussion


      Matt in http://community.jboss.org/thread/162048?start=30&tstart=0  says


      Not sure if this is a bug, or functionality that hasn't been implemented yet-


      Trying to add attributes to the SAML response, created a class that implements AttributeManager and pulls data from our own in-house person manager tool (backend is LDAP, database and other authoritative sources).  It seems to work properly but when it tries to build the SAML response I get :


      2011-03-10 15:41:01,474 ERROR [org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler] (ajp- Exception in processing authentication:

      java.lang.RuntimeException: Unknown:guid

              at org.picketlink.identity.federation.core.saml.v2.util.StatementUtil.createAttributeStatement(StatementUtil.java:139)


      From what I can decern it looks like its trying to convert the attrbitue names into a standard naming convention.   But in StatementUtil only 4 of the dozen or so attributes in AttributeConstants seem to be implemented, and I don't see that anything has been implemented to handle the attributes that don't fall under the X500 spec.




      This discussion thread is for the SAML Attributes functionality in PicketLink.

        • 1. SAML Attributes Discussion

          Created https://issues.jboss.org/browse/PLFED-158


          For the stuff that doesn't fall under the X500 spec how were you thinking of implementing it?

          • 2. SAML Attributes Discussion

            If you look at AssertionUtil,  there is a method for creating an attribute type.  In my view, rather than just throw a RTE in StatementUtil, we should just create a AttributeType using AssertionUtil (or just directly create it).


            You signed the CLA (http://jboss.org/contribute) ?   Once that is done, I can get the commit rights out to you.

            • 3. SAML Attributes Discussion

              I'll look at that.  Yes, I didn't see one for Picketlink, so I did JBoss Federated SSO, let me know if I need to select a different one.  Also I ssume you have a different subversion repository for commits than anonsvn.jboss.org?

              • 4. SAML Attributes Discussion

                Matt,  choose "JBoss Identity".   Yeah. we have a different svn repo for PL for commits.

                • 5. SAML Attributes Discussion

                  Matt,  you should have access.  If you change something, update the appropriate test case or add a new test case.  I am sure you can figure out which test.

                  • 6. SAML Attributes Discussion

                    I'm seeing some of these attribute have different friendly values depending on where you look (cn vs commonName, sn vs surname, etc).  Do you want me to do multiple entries for each?  Only problem would be if you ever want to go from uri to friendly name you'd have non-unique mapping.  Alternatively I could add another field for an alternate name (I've yet to see more than two).   I know the LDAP we have here uses the shorter ones but I'm not sure if that is a standard or a configuration.


                    Example of mulitple entries:

                       CN               ("cn",                  "urn:oid:"),

                       COMMON_NAME      ("commonName",          "urn:oid:"),

                       SN               ("sn",                  "urn:oid:"),

                       SURNAME          ("surname",             "urn:oid:"),

                       L                ("l",                   "urn:oid:"),

                       LOCALITY         ("localityName",        "urn:oid:"),

                       ST               ("st",                  "urn:oid:"),

                       STATE_PROVIDENCE ("stateOrProvinceName", "urn:oid:"),

                       STREET           ("street",              "urn:oid:"),

                       TITLE            ("title",               "urn:oid:"),

                       POSTAL_CODE      ("postalCode",          "urn:oid:"),

                       TELEPHONE        ("telephoneNumber",     "urn:oid:"),

                       GIVENNAME        ("givenName",           "urn:oid:"),

                    • 7. SAML Attributes Discussion

                      I would be more worried about the URI rather than the Friendly Name.  I have to dig into the x500 and ldap specs to see why the mismatch exists.

                      • 8. SAML Attributes Discussion

                        Also if you are using eclipse, check the formatting templates.


                        • 9. SAML Attributes Discussion

                          No problem, I had it in columns cause it was easier to read which ones were missing (got mangled going from fixed width to variable width font).  I'll reformat before committing.

                          • 10. SAML Attributes Discussion

                            I found a decent list of friendly name to X500 name mapping.  Similar to most of the otherplaces I found that several friendly names mapped to a single X500 name.  I have to assume that's why they set this style up to eliminate the various naming across configurations.  I reorganized the list in numerical assending order just to get a better handle on the duplciates and see how much was missing.  Should make it easier to remove the duplicates as well.




                            Its by no means a complete list and something you might want to think about from a design perspective is changing it from a enum to an XML file that gets parsed on startup.  That way the list can be updated without recompiling everything.  Some of the numeric groupings seems to be geared more towards educational use and some seemed to be stuff that would only very rarely be used.  This method might make it easier to pare back the lesser used stuff for more efficient processing. 


                            I tweaked the enum class to hold a static map of the friendly name to the x500 name.  Avoided the long list of if statements in StatementUtil and replaced them with a simpler lookup, scales a bit better.


                               private static final Map<String, X500SAMLProfileConstants> lookup = new HashMap<String, X500SAMLProfileConstants>();

                               static {         

                                   for(X500SAMLProfileConstants x500 : X500SAMLProfileConstants.values())

                                       lookup.put(x500.getFriendlyName(), x500);    



                               public static X500SAMLProfileConstants get(String firendlyName) {

                                   return lookup.get(firendlyName);



                            As I was testing this I noticed for the non-X500 stuff I was getting a


                            java.lang.RuntimeException: Unsupported attribute value:com.mycompany.Person

                                    at org.picketlink.identity.federation.core.saml.v2.writers.BaseWriter.writeAttributeTypeWithoutRootTag(BaseWriter.java:177)


                            In looking through the code it currently has only been setup to handle strings.  I believe when I was looking through the specs (can't find where I saw it at the moment) it allows for base 64 encoded data (for binary data) and I believe it also allowed for more complex namespaces in the values.  Did you have anything in mind for this yet?

                            I figured requiring the class be either serializable or annotated as @XmlRootElement,etc might offer a few options for a generic way to trasmit the data, the later making it more portable to non-java implementations. 

                            • 11. SAML Attributes Discussion

                              I have to jump back onto something else for a bit but I did find two things in my testing

                              1)  On those changes you made to StringUtil, getSystemPropertyAsString, it wasn't handling a null parameters, which is whenever the attribute isn't filled in. 


                              2) Whenever additional attributes beyond the roles are returned is creates two attributestatement blocks.  I haven't had a chance to verify if this is valid XM but at least on the seam example app it seems to only be seeing the second block and ignoring the first. 

                              --- SNIP ---

                                  <saml:Attribute Name="Role">

                                      <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user</saml:AttributeValue>




                                  <saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" FriendlyName="gn" Name="urn:oid:" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" x500:Encoding="LDAP">

                                      <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Matthew</saml:AttributeValue>


                              --- SNIP ---

                              • 12. SAML Attributes Discussion

                                https://issues.jboss.org/browse/PLFED-160   for the attribute statements.


                                Regarding the constants, I still prefer an enum to an external xml file because we still package the file as part of the jar.  If we need a newer set of constants, we just update the enum and regenerate the jar.


                                I know, at this time, I have just considered string attributes.  We need to handle the other types of attributes too. 


                                I take the use case based approach.  When there are use cases, we fill in the gaps.

                                • 13. SAML Attributes Discussion

                                  That's cool, enums seem to be working fine at this point.


                                  Completely understandable.  You don't want to produce code to handle functionality nobody ends up using.  The request I had on my side was to include the user's picture.  I did a quick test and was able to do marshalling (or serialization) prior and using the resulting xml as a string so I could always fall back on that for now.  I can look into the difficulty of adding this into the attribute writer.

                                  • 14. SAML Attributes Discussion

                                    Matt, if you update the workspaces, you will see that I removed the large if/then block for x500 attrib parsing in StatementUtil.

                                    1 2 Previous Next