Combination View Flat View Tree View
Threads [ Previous | Next ]
Showing 1 - 20 of 75 results.
of 4
Matthew Stevenson
Using SAML authentication with existing IdP - user mapping issue?
May 17, 2012 3:37 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

I am having some issues getting the SAML portlet provided with Liferay 6.1EE to work with our existing IdP.

First question: where is the official documentation for this portlet? I have only been able to find snippets of information in blog posts etc so far.

Specific issue:

I roughly followed the Service Provider part of this guide in order to get my Liferay development environment configured for SSO: http://blogs.xtivia.com/home/-/blogs/configuring-liferay-6-1-ee-as-saml-identity-provider-and-service-provider

I had to make a few tweaks to get it all working over SSL, but now the login process seems to be flowing properly - when I click “Sign In” I am redirected to the IdP login page, and when I authenticate correctly, I am returned to the Liferay site. The problem is that when I arrive back at the Liferay site, I am not logged in.

I assume this is because Liferay doesn't have enough information to know who I have authenticated as. How does Liferay work out which user I am logged in as? There is a line in the portal-ext.properties file like so:

saml.sp.user.attribute.mappings=

Do I need to pass something in here so that it can match my federated account up to an existing Liferay account, and if so, what?

Thanks,
Matt
Mika Koivisto
RE: Using SAML authentication with existing IdP - user mapping issue?
May 17, 2012 11:55 AM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

It's the name identifier what Liferay uses as the authenticated user. If it can't find the user from Liferay database it will either try to import it from ldap (if enabled) or use the attribute statements from the saml assertion. If you use email address for the nameid the idp needs to set the nameid format to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress anything else will be interpreted as screenName.

Here's a sample config for sp with attribute mapping:

 1saml.enabled=true
 2saml.role=sp
 3saml.entity.id=liferaysamlspdemo
 4saml.require.ssl=false
 5saml.sign.metadata=true
 6
 7saml.keystore.path=${liferay.home}/data/keystore.jks
 8saml.keystore.password=liferay
 9saml.keystore.type=jks
10
11saml.keystore.credential.password[liferaysamlspdemo]=liferay
12
13saml.metadata.paths=http://alpha.test.com:8080/c/portal/saml/metadata
14saml.sp.default.idp.entity.id=liferaysamlidpdemo
15
16saml.sp.user.attribute.mappings=screenName=screenName\nemailAddress=emailAddress\nfirstName=firstName\nlastName=myCustomAttribute


Just out of curiosity what IdP are you using?

I would also like to hear what improvements you'd like to see in the next version of saml plugin.
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
May 18, 2012 5:16 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

Hi Mika,

My Liferay is set to use screenName, and my IdP (it's OpenAthens LA by the way) can send back an appropriate attribute called username, but if I put the following in portal-ext.properties, it still doesn't log me in:

1saml.sp.user.attribute.mappings=screenName=username


I have checked the SAMLResponse, and the username attribute is definitely being passed through in there. How can I find out why it's not matching up the user?

Regarding future enhancements, I am sure that I will be able to come up with some, but because I'm not sure what the feature set of the current version is I can't do that just yet!
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
May 18, 2012 5:28 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

This is the only info in the console, I don't know if it helps:

12:27:08,367 ERROR [AutoLoginFilter:239] Current URL / generates exception: java.lang.NullPointerException
12:27:08,370 ERROR [AutoLoginFilter:239] Current URL / generates exception: java.lang.NullPointerException
12:27:17,989 INFO [SAMLProtocolMessageXMLSignatureSecurityPolicyRule:121] Validation of protocol message signature succeeded, message type: {urn:oasis:names:tc:SAML:2.0:protocol}Response
12:27:18,160 ERROR [AutoLoginFilter:239] Current URL / generates exception: java.lang.NullPointerException
12:27:18,161 ERROR [AutoLoginFilter:239] Current URL / generates exception: java.lang.NullPointerException
Mika Koivisto
RE: Using SAML authentication with existing IdP - user mapping issue?
May 18, 2012 10:11 AM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

You should enable DEBUG level logging for org.opensaml that way you can see what kind a SAML response it's actually sending.
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
May 21, 2012 3:58 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

Sorry Mika, I think I'm going to need a hand...

I've tried adding the line
1org.opensaml = DEBUG

to the tomcat logging.properties, and have also tried the approach outlined here:
http://www.liferay.com/community/wiki/-/wiki/Main/How+to+configure+the+logs+in+Liferay

by deploying a jar containing META-INF/portal-log4j-ext.xml with the following contents:

1<?xml version="1.0"?>
2<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
3
4<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
5    <category name="org.opensaml">      
6        <priority value="DEBUG" />
7    </category>
8</log4j:configuration>


Neither of these has resulted in anything extra coming through on the console though. Where do I need to enable this?
Mika Koivisto
RE: Using SAML authentication with existing IdP - user mapping issue?
May 21, 2012 5:40 PM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

Looks like the saml message is actually logged by org.apache.xml.security.utils.DigesterOutputStream. I usually just enable the logging from Control Panel -> Server Administration -> Log Levels or directly in the saml-portlet/WEB-INF/classes/log4j.properties and set the rootLogger to DEBUG.
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
May 22, 2012 2:33 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

I've made a bit more progress with this by attaching the source code and running in debug mode.

First problem was that Liferay was trying to trim an email address that it assumed would be present, and throwing a NullPointerException when it didn't find one (I wasn't passing the email address as an attribute, and in a SSO scenario I shouldn't need to but that's another topic!).

By passing email address as an attribute, it seems to be getting past this, but now I get a DuplicateUserScreenNameException. It appears that in the file SamlSpAutoLoginHook.java the attempt to set the user with:

1user = UserLocalServiceUtil.getUserByScreenName(companyId, nameIdValue);


is failing, and it therefore attempts to create the user, at which point it finds out that the username already exists and throws the exception.

In the above call to getUserByScreenName, the nameIdValue is set to an unrecognizable string: IZLF_KzsEUIW_FXZsBzpCV6qyRBqFRDK which is different from the screenName taken from the attribute map. I don't know whether this is to be expected?
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
May 22, 2012 8:32 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

Mika,

A few issues I'm finding with the plugin:

In the SAMLResponse sent by my IDP, both of the following are present:

1
2<saml:NameID NameQualifier="https://login.uea.ac.uk/entity" SPNameQualifier="samlspdemo" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">yDKHiOgNm_mKyAHAkz_TeIOlwdROFYfN</saml:NameID>
3
4<saml:NameID NameQualifier="https://login.uea.ac.uk/entity" SPNameQualifier="samlspdemo" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">PpiUBF11Nak/b86AqJUQiAVs8xs=</saml:NameID>


The string that that the SAML plugin is trying to search for existing users by (NameID) appears to be populated with the transient version, not the persistent. The result is that if I try and log in as a new user (and pass all the required attributes), an account is generated on-demand. However, because the transient NameID changes with each login, the next time I log in, this ID has changed, and I don't get logged in to my newly created account. Instead, I get the DuplicateUserScreenNameException mentioned in the previous post.

Secondly, after an account has been auto-generated as mentioned, on login I am presented with the "change password" and "security question". For an SSO account, these don't really apply. Is there a way to make these screens not appear?

The main issue I think we are going to have though, is that our portal is already populated with users and we just want to switch on SAML authentication, matching up users by screenName. However, the plugin doesn't appear to be able to match up users like this, and instead assumes that they have been created via SAML and already have a matching NameID value stored against the user.

If you are able to help on these points I'd appreciate it.
Mika Koivisto
RE: Using SAML authentication with existing IdP - user mapping issue?
May 23, 2012 1:54 PM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

The SP implementation is currently very limited and only supports one NameID which has to be either a emailAddress or screenName and it has to not change between logins. It will use the assertion which has subject confirmation method urn:oasis:names:tc:SAML:2.0:cm:bearer.

Can you post you full saml response? Just X out any sensitive data. I'm interested to see if it's a bug or if it's just a limitation that I can address in a future version.
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
May 24, 2012 2:32 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

Hi Mika,

I see. I think it's possibly a combination of bug and limitation in that case, but would like to hear your thoughts on it. I'm more than happy to work with you to fine tune the SP's behaviour:

Bug because it's picking out a transient NameID rather than a persistent one.

Limitation in a couple of ways:
1. Because it is assuming that the NameID is populated with a screenName or email address whereas with most IdPs in the wild that I'm aware of (Shibboleth is used heavily in the education sector), populate these with "opaque" values that are non-identifiable as far as the user is concerned.

2. It would be better to be able to specify which attribute should be used as the persistent ID. E.g. with the way it's currently working, I would need to be able to specify the "username" attribute in the xml below as the screenName rather than it automatically picking out the persistent NameID value.

However, it would be preferable to use the persistent ID as the unique ID, and also have a way to match people up to existing accounts (if present) via a seperately specified screenName/emailAddress attribute. The use case here is that if we have an existing liferay DB (with people with screenNames), that SAML sign in can be enabled and their SAML persistentID is attached to their existing user account and that is used to match them from then on. An attribute mapped to screenName would be used as a one-off to link the SAML ID to the existing liferay user account. This way, if the screenName is not present as an attribute (e.g. if the SAML authentication has come from an IdP in a different organisation) we can create them a new guest account using only SAML persistent ID. Internally I guess liferay would have to set their screenName to be the persistentID (which is something that the user doesn't recognise as their username), but hopefully they won't need to see that.

Here's the full SAML Response (the "eduPerson" attributes are widely used in the eduation sector so that IdPs and SPs can interoperate with minimal configuration):

  1<?xml version="1.0" encoding="utf-8"?>
  2<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="tbs_ik0_nhHDXnN0NfEjNrwyGDg6Ur6l" IssueInstant="2012-05-24T08:18:21Z" Version="2.0" InResponseTo="_6582af87cd60059502faec6709055539f460e952" Destination="https://xxxxxxxxxxx:8443/c/portal/saml/acs">
  3    <saml:Issuer>https://login.uea.ac.uk/entity</saml:Issuer>
  4    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  5        <ds:SignedInfo>
  6            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
  7            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
  8            <ds:Reference URI="#tbs_ik0_nhHDXnN0NfEjNrwyGDg6Ur6l">
  9                <ds:Transforms>
 10                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
 11                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
 12                </ds:Transforms>
 13                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
 14                <ds:DigestValue>Jmd7VJsgsshQA1tFBxoHiggVVMs=</ds:DigestValue>
 15            </ds:Reference>
 16        </ds:SignedInfo>
 17        <ds:SignatureValue>DvNcc2RjSL0hfh9mMJ5Cc04IjE7OGgvv0UuT+trd70AszYwgrVrRWttet6esWizj
 18xq5CbPc6DJ7Wie64mzeWreQuJ0uwAWWtS25ufhVsG0WqAcvSePiIx3s9GWWV+8z6
 19s0jn1rK4T6Q3iPj768sliwXIdsS+jQ95xhDXfBZ2LGs7+94uA2cz1SGNVFd1p+8/
 20DkopziHosmxc7/DC2hEjw/rpl6AZKVueWRqxjBuVjzh2qzNffrudAeH0d/ex5Vv0
 21E5haHllnVn/G7eEBA9iygHFDaMMbFpJv+bL8xUUFLii8Z5gE9Yi6C8JoaN7mc9dg
 22QiFp2Tlyv9Od8cr2wjQ6AQ==</ds:SignatureValue>
 23        <ds:KeyInfo>
 24            <ds:X509Data>
 25                <ds:X509Certificate>MIIDoDCCAoigAwIBAgIJAIuKNtoJUQjXMA0GCSqGSIb3DQEBBQUAMD4xIjAgBgNV
 26BAoTGVVuaXZlcnNpdHkgb2YgRWFzdCBBbmdsaWExGDAWBgNVBAMTD2xvZ2luLnVl
 27YS5hYy51azAeFw0xMDExMDkwNzU3NTJaFw0yMDExMDYwNzU3NTJaMD4xIjAgBgNV
 28BAoTGVVuaXZlcnNpdHkgb2YgRWFzdCBBbmdsaWExGDAWBgNVBAMTD2xvZ2luLnVl
 29YS5hYy51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM9oeuK7k5dK
 30bp97dCPSq7gqVrm3Rq2fyW62SFx1IVwFBtoW1CIQOkDJF8bVkKa2U+dMmwLHvfEP
 31qVnXXA59eDJeGRib2ME6o1q90McllqBVWhuBoR08GFEdXhbt1lpUpBNOF+V9lv+y
 32f37bDm2ii+iaCaOcaT5sO9g0krqw/mlWsSPUIhAG7TzndSECH4lHdqBEWPlk87gn
 335LeuezjWpgQmdPD6PaB2fuTyQyP+BeNeIK8EiJvCpBzA92EKitTHxTa6ON3LEy0L
 34qzJCDWx7rq0R0ch7TmzGw8DLrKIWRHbfH2nMWMFMp7Hf1EhB/Z1+R7nhgIV6HxQi
 35d+DmuhrLJB8CAwEAAaOBoDCBnTAdBgNVHQ4EFgQUREAlXs64Gbcn4E+0R5mumL5k
 36+MwwbgYDVR0jBGcwZYAUREAlXs64Gbcn4E+0R5mumL5k+MyhQqRAMD4xIjAgBgNV
 37BAoTGVVuaXZlcnNpdHkgb2YgRWFzdCBBbmdsaWExGDAWBgNVBAMTD2xvZ2luLnVl
 38YS5hYy51a4IJAIuKNtoJUQjXMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD
 39ggEBAKhau/vUIiWf7K2ILlfdK89NKLuvUwndns9sYEcIFAqTMWnGlpXogPzFUqvd
 40PTEjYSkffvr5xHPIasBpaouVmqsr245P1aX9qZh4f6K7FLS+hUHdJvaFrGl6oxEe
 41WPILAJimme/YZqVCmyyLeYAB+l9Yt81wd+xkaajOrbNalv2f1fxIwQpGp3oosR3b
 42WXVQwwCnZX7KrZHmIfiRvY9yYctOsXs1xlbZoR8m0F5Tq3xOZIoHjOoWyl4AARFM
 43NpCaUKSy/eK1MvlZph0VK6QY4P7xlZMvEnMQscrf/bEBblQ+dGyfM664mnPAvWgR
 44nIhXWvtGhtoIysHU01bNRSH11OA=</ds:X509Certificate>
 45            </ds:X509Data>
 46        </ds:KeyInfo>
 47    </ds:Signature>
 48    <samlp:Status>
 49        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
 50    </samlp:Status>
 51    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="SgNnSkV9Bfo4Q4SGgiKXRYELurf93e66" IssueInstant="2012-05-24T08:18:21Z" Version="2.0">
 52        <saml:Issuer>https://login.uea.ac.uk/entity</saml:Issuer>
 53        <saml:Subject>
 54            <saml:NameID NameQualifier="https://login.uea.ac.uk/entity" SPNameQualifier="samlspdemo" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">DwbzSlmx76O0Vu760_P0DDd4krmbKv4d</saml:NameID>
 55            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
 56                <saml:SubjectConfirmationData Recipient="https://xxxxxxxxxxxxx:8443/c/portal/saml/acs" NotOnOrAfter="2012-05-24T08:23:21Z"/>
 57            </saml:SubjectConfirmation>
 58        </saml:Subject>
 59        <saml:Conditions NotBefore="2012-05-24T08:13:21Z" NotOnOrAfter="2012-05-24T08:23:21Z">
 60            <saml:AudienceRestriction>
 61                <saml:Audience>samlspdemo</saml:Audience>
 62            </saml:AudienceRestriction>
 63        </saml:Conditions>
 64        <saml:AuthnStatement AuthnInstant="2012-05-24T08:17:01Z" SessionIndex="8b0921a0ec8123efb059e1dae8d1b3e0adc32227">
 65            <saml:SubjectLocality Address="xxx.xxx.xxx.xxx"/>
 66            <saml:AuthnContext>
 67                <saml:AuthnContextDeclRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextDeclRef>
 68            </saml:AuthnContext>
 69        </saml:AuthnStatement>
 70        <saml:AttributeStatement>
 71            <saml:Attribute Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 72                <saml:AttributeValue>xxxxxxxxxxx</saml:AttributeValue>
 73            </saml:Attribute>
 74            <saml:Attribute Name="surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 75                <saml:AttributeValue>xxxxxxxxxx</saml:AttributeValue>
 76            </saml:Attribute>
 77            <saml:Attribute Name="forename" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 78                <saml:AttributeValue>xxxxxxxxx</saml:AttributeValue>
 79            </saml:Attribute>
 80            <saml:Attribute Name="urn:mace:dir:attribute-def:eduPersonTargetedID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 81                <saml:AttributeValue>PpiUBF11Nak/b86AqJUQiAVs8xs=</saml:AttributeValue>
 82            </saml:Attribute>
 83            <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 84                <saml:AttributeValue>
 85                    <saml:NameID NameQualifier="https://login.uea.ac.uk/entity" SPNameQualifier="samlspdemo" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">PpiUBF11Nak/b86AqJUQiAVs8xs=</saml:NameID>
 86                </saml:AttributeValue>
 87            </saml:Attribute>
 88            <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 89                <saml:AttributeValue>member</saml:AttributeValue>
 90                <saml:AttributeValue>employee</saml:AttributeValue>
 91                <saml:AttributeValue>staff</saml:AttributeValue>
 92            </saml:Attribute>
 93            <saml:Attribute Name="eduPersonScopedAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 94                <saml:AttributeValue>member@uea.ac.uk</saml:AttributeValue>
 95                <saml:AttributeValue>employee@uea.ac.uk</saml:AttributeValue>
 96                <saml:AttributeValue>staff@uea.ac.uk</saml:AttributeValue>
 97            </saml:Attribute>
 98            <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
 99                <saml:AttributeValue>xxxxxxxxxxxx</saml:AttributeValue>
100            </saml:Attribute>
101            <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
102                <saml:AttributeValue>member@uea.ac.uk</saml:AttributeValue>
103                <saml:AttributeValue>employee@uea.ac.uk</saml:AttributeValue>
104                <saml:AttributeValue>staff@uea.ac.uk</saml:AttributeValue>
105            </saml:Attribute>
106            <saml:Attribute Name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
107                <saml:AttributeValue>member@uea.ac.uk</saml:AttributeValue>
108                <saml:AttributeValue>employee@uea.ac.uk</saml:AttributeValue>
109                <saml:AttributeValue>staff@uea.ac.uk</saml:AttributeValue>
110            </saml:Attribute>
111            <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
112                <saml:AttributeValue>member</saml:AttributeValue>
113                <saml:AttributeValue>employee</saml:AttributeValue>
114                <saml:AttributeValue>staff</saml:AttributeValue>
115            </saml:Attribute>
116            <saml:Attribute Name="eduPersonTargetedID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
117                <saml:AttributeValue>PpiUBF11Nak/b86AqJUQiAVs8xs=</saml:AttributeValue>
118            </saml:Attribute>
119            <saml:Attribute Name="urn:mace:dir:attribute-def:eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
120                <saml:AttributeValue>member</saml:AttributeValue>
121                <saml:AttributeValue>employee</saml:AttributeValue>
122                <saml:AttributeValue>staff</saml:AttributeValue>
123            </saml:Attribute>
124        </saml:AttributeStatement>
125    </saml:Assertion>
126</samlp:Response>
Mika Koivisto
RE: Using SAML authentication with existing IdP - user mapping issue?
May 24, 2012 2:09 PM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

Ahaa. I see what the issue is. Your Subject contains the transient value and that's what we use. There's currently no support for picking up the principal name from SAML attributes. I'm planning on adding that feature for the next major version of SAML plugin but in the mean time you can modify SamlSpAutoLoginHook class to dig the NameID from the attributes instead of using the one that's taken from subject.
Chris Mount
RE: Using SAML authentication with existing IdP - user mapping issue?
May 31, 2012 7:43 AM
Answer

Chris Mount

Rank: New Member

Posts: 10

Join Date: April 6, 2012

Recent Posts

Hey Mika and Matthew thanks so much for this dialog. The timeliness could not be more perfect. I was having the same problem and was able to modify the SamlSpAutoLoginHook class to get the NameID to populate from the saml attributes. If this makes sense, in my situation, I believe it is federal requirement that only persistent, transient, or unspecified are used, so when I specify unspecified as the format, in our case the NameID field was populated with an email address, but that gets interpreted as the screenName. Our login is set to screenName is mapped to an LDAP user id attribute. So in short the code change I made allowed me to specify via a property setting what attribute to authenticate by.
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
June 13, 2012 1:34 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

Hi, I've done something similar - making it pick out the nameIdValue from an attribute, which seems to be working.

I still haven't managed to work out the cause of the errors which occur on every page request:
109:26:01,785 ERROR [AutoLoginFilter:239] Current URL / generates exception: java.lang.NullPointerException
209:26:03,585 ERROR [AutoLoginFilter:239] Current URL /web/guest/home generates exception: java.lang.NullPointerException


Do you get these errors too?

Mika, does the SAML portlet insert itself into the Authentication Pipeline, or only the auto-login filter? The reason I ask is that I have also set up Facebook authentication, and when I click on the Facebook icon in the login portlet, I can authenticate at Facebook, but then Liferay redirects me to the SAML IdP. If I then press the back button in the browser, I find that I am logged into the portal ok (using my Facebook account).

I'm not sure why I'm ending up at the SAML IdP after clicking the Facebook login page - any ideas?
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
June 13, 2012 3:19 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

Don't worry about the error lines - I've found the cause (my fault), just happened to be the same error that I was getting at the beginning, but the cause was different then.

Query about the Auth Pipeline still applies though.
Mika Koivisto
RE: Using SAML authentication with existing IdP - user mapping issue?
June 13, 2012 10:02 AM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

SAML SP doesn't work with the other authentication mechanisms but that is something I have in the roadmap.
Matthew Stevenson
RE: Using SAML authentication with existing IdP - user mapping issue?
June 14, 2012 4:13 AM
Answer

Matthew Stevenson

Rank: New Member

Posts: 12

Join Date: May 17, 2012

Recent Posts

Ah ok, I think this should be quite high on the list of enhancement priorities.

Do you know what the timescales are for including some of these extra features?

In our scenario, we are looking for SAML authentication for our internal users, but to allow guests to log in via facebook, OpenID or other SAML IdP etc. I would like to know what you think is the best way of altering the sign-in process to allow this. In particular, if someone visits a private page (e.g. intranet), we would like to attempt to detect if someone is on an internal IP address and if so attempt a SAML autologin. If that fails, then we should present them with a screen where they can choose which authentication method to use. I was thinking of writing a replacement AutoLogin filter to achieve this, but because you would end up requiring user input (choose auth method) I'm not sure this is the best thing to do. Any thoughts?

Thanks,
Matt
Peter J Shields
RE: Using SAML authentication with existing IdP - user mapping issue?
October 16, 2012 11:35 AM
Answer

Peter J Shields

Rank: New Member

Posts: 15

Join Date: June 30, 2009

Recent Posts

I am configuring the SAML 2 plugin as an SP and attempting to use it with a Shibboleth IDP. So far, I've got a working config on the plugin where it is able to load and refer an AuthnRequest to Shibboleth, where the login actually happens. The Shibboleth IDP then generates a SAML response as follows after successful login:

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="http://xxxxxxxxxxxxxxx.com:8080/c/portal/saml/acs"
ID="_50f9ae953638fbc3c970f3ad9585d35b"
InResponseTo="_80f0ebd4e2061df90ebe7e6d3a8298591042bb5e"
IssueInstant="2012-10-16T17:30:55.867Z"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>lrhddev.hdna.hunterdouglas.com</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />emoticon
</saml2p:Status>

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_3018ef5505b30baa32dc64fb063d7783"
IssueInstant="2012-10-16T17:30:55.867Z"
Version="2.0"
>
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">xxxxxxxxxxxxxxx.com</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_3018ef5505b30baa32dc64fb063d7783">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<dsemoticonigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsemoticonigestValue>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</dsemoticonigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
NameQualifier="xxxxxxxxxxxxxxx.com"
SPNameQualifier="xxxxxxxxxxxxxxx.com"
>MyUserName</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="172.31.6.23"
InResponseTo="_80f0ebd4e2061df90ebe7e6d3a8298591042bb5e"
NotOnOrAfter="2012-10-16T17:35:55.867Z"
Recipient="http://portal.xxxxxxxxxxxxxxx.com:8080/c/portal/saml/acs"
/>
</saml2:SubjectConfirmation>
</saml2:Subject>

<saml2:Conditions NotBefore="2012-10-16T17:30:55.867Z"
NotOnOrAfter="2012-10-16T17:35:55.867Z"
>
<saml2:AudienceRestriction>
<saml2:Audience>xxxxxxxxxxxxxxx.com</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2012-10-16T17:30:55.463Z"
SessionIndex="15e62d8afa22592858f7deb4a140773b1b322a04eebf05e9eede3f9df3d37bc6"
>
<saml2:SubjectLocality Address="172.31.6.23" />
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classesemoticonasswordProtectedTransport</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</saml2p:Response>

This looks to be a properly formatted SAML response, but instead of doing the auto-login as expected, the SAML 2 plugin throws the following errors:

12:29:44,360 INFO [http-bio-8080-exec-9][AbstractReloadingMetadataProvider:122] New metadata succesfully loaded for '/usr/local/liferay/data/saml/idp-metadata.xml'
12:29:44,360 INFO [http-bio-8080-exec-9][AbstractReloadingMetadataProvider:142] Next refresh cycle for metadata provider '/usr/local/liferay/data/saml/idp-metadata.xml' will occur on '2012-10-16T15:29:44.348Z' ('2012-10-16T15:29:44.348Z' local time)
12:29:51,492 INFO [http-bio-8080-exec-9][SAMLProtocolMessageXMLSignatureSecurityPolicyRule:114] SAML protocol message was not signed, skipping XML signature processing
12:29:51,492 ERROR [http-bio-8080-exec-9][MandatoryAuthenticatedMessageRule:76] Inbound message issuer was not authenticated.
12:29:51,567 ERROR [http-bio-8080-exec-9][status_jsp:665] com.liferay.saml.SamlException: org.opensaml.ws.security.SecurityPolicyException: Inbound message issuer was not authenticated.
com.liferay.saml.SamlException: org.opensaml.ws.security.SecurityPolicyException: Inbound message issuer was not authenticated.
at com.liferay.saml.profile.WebSsoProfileImpl.processResponse(WebSsoProfileImpl.java:149)
at com.liferay.saml.profile.WebSsoProfileUtil.processResponse(WebSsoProfileUtil.java:43)
at com.liferay.saml.hook.action.AssertionConsumerServiceAction.execute(AssertionConsumerServiceAction.java:40)
...
Caused by: org.opensaml.ws.security.SecurityPolicyException: Inbound message issuer was not authenticated.
at org.opensaml.ws.security.provider.MandatoryAuthenticatedMessageRule.evaluate(MandatoryAuthenticatedMessageRule.java:38)
at org.opensaml.ws.security.provider.BasicSecurityPolicy.evaluate(BasicSecurityPolicy.java:51)
at org.opensaml.ws.message.decoder.BaseMessageDecoder.processSecurityPolicy(BaseMessageDecoder.java:132)
at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:83)
at org.opensaml.saml2.binding.decoding.BaseSAML2MessageDecoder.decode(BaseSAML2MessageDecoder.java:70)
at com.liferay.saml.profile.BaseProfile.decodeSamlMessage(BaseProfile.java:73)
at com.liferay.saml.profile.WebSsoProfileImpl.doProcessResponse(WebSsoProfileImpl.java:385)
at com.liferay.saml.profile.WebSsoProfileImpl.processResponse(WebSsoProfileImpl.java:139)
... 90 more

What is the plugin expecting to validate the AuthnRequest was successful, does it not use message status <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />? What am I missing?

Is there any way to correct this seemingly odd behavior?
Mika Koivisto
RE: Using SAML authentication with existing IdP - user mapping issue?
October 16, 2012 11:56 AM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1498

Join Date: August 7, 2006

Recent Posts

Following lines says it all. The SAML message wasn't signed by your IdP. Do you have signing keys in the SAML metadata on both sides?

112:29:51,492 INFO [http-bio-8080-exec-9][SAMLProtocolMessageXMLSignatureSecurityPolicyRule:114] SAML protocol message was not signed, skipping XML signature processing
212:29:51,492 ERROR [http-bio-8080-exec-9][MandatoryAuthenticatedMessageRule:76] Inbound message issuer was not authenticated.
Peter J Shields
RE: Using SAML authentication with existing IdP - user mapping issue?
October 16, 2012 12:02 PM
Answer

Peter J Shields

Rank: New Member

Posts: 15

Join Date: June 30, 2009

Recent Posts

One more thing ...

The SAML assertion passed to the IDP specifies the following:

<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://xxxxxxxxxxxxxxx.com:8080/c/portal/saml/acs"
Destination="https://xxxxxxxxxxxxxxx.com/idp/profile/SAML2/Redirect/SSO"
ForceAuthn="false"
ID="_e35b665028c22e155a8a47186d972fa540ac5698"
IsPassive="false"
IssueInstant="2012-10-16T18:44:25.786Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">xxxxxxxxxxxxxxx.com</saml2:Issuer>
<saml2p:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
SPNameQualifier="xxxxxxxxxxxxxxx.com"
/>

</saml2p:AuthnRequest>

In previous posts you stated "If you use email address for the nameid the idp needs to set the nameid format to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress anything else will be interpreted as screenName."

I've tried configuring the IDP to return the screen name (cn) as NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", expecting that this will be correctly interpreted as a screen name. Unfortunately, if the format is anything but “emailAddress”, regardless of the kind of value returned, the IDP will return an error because the required NameID format is unavailable. The following was generated by attempting to return the screenName (cn) using the “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified” NameID format.

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="http://xxxxxxxxxxxxxxx.com:8080/c/portal/saml/acs"
ID="_b1a139ed3b109a9e70c7938b229e3e69"
InResponseTo="_7c2d9c2133360df694a90fd5324ea1a1489d0bc3"
IssueInstant="2012-10-16T12:47:24.134Z"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>xxxxxxxxxxxxxxx.com</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" />
</saml2p:StatusCode>
<saml2p:StatusMessage>Required NameID format not supported</saml2p:StatusMessage>
</saml2p:Status>
</saml2p:Response>

Is there something missing in my SAML 2 config that would allow for a non-emailAddress formatted response?
Showing 1 - 20 of 75 results.
of 4