By: Hugo Brakman user 21 Feb 2017 at 7:31 a.m. CST

15 Responses
Hugo Brakman gravatar
Hi support, We are setting up a configuration with multiple IDPs and multiple SPs where an SP is not always served by all IDPs. At the moment our setup and sequence is like this: User -> SP -> Asimba -> some IDP We managed to adjust the selector page so we can filter the suggested IDP list based on the SP as we needed. Thanks for this suggestion, it works for our case. If you look at the diagram here: https://www.gluu.org/blog/use-case-for-asimba-as-saml-proxy/ it suggests IDPs connect directly to Asimba and SPs also connect directly to Asimba. Is this the recommended setup? How do we embellish the claims from the external IDPs with additional information that we would normally store on our side? E.g. the organization name, which is not provided by the external IDP perhaps. How do the SPs deal with the possibly different names the different external IDPs give to the same attribute? (Such as user.name versus userName or userid) I could not find further information on these details and would much appreciate any recommendations. Thanks in advance, Hugo

By Mohib Zico Account Admin 21 Feb 2017 at 7:49 a.m. CST

Mohib Zico gravatar
>> If you look at the diagram here: https://www.gluu.org/blog/use-case-for-asimba-as-saml-proxy/ it suggests IDPs connect directly to Asimba and SPs also connect directly to Asimba. Is this the recommended setup? That is an old blog. All SP will be connected to your Gluu Server Shibboleth. Remote IDP will be connected to Asimba part of Gluu Server. >> How do we embellish the claims from the external IDPs with additional information that we would normally store on our side? E.g. the organization name, which is not provided by the external IDP perhaps. Why would you want to do that? Any use case? >> How do the SPs deal with the possibly different names the different external IDPs give to the same attribute? (Such as user.name versus userName or userid) 'Asimba' script has a custom property named 'saml_idp_attributes_mapping' which does that for us.

By Hugo Brakman user 22 Feb 2017 at 1:59 a.m. CST

Hugo Brakman gravatar
Thanks Mohib Zico, "All SP will be connected to your gluu server Shibboleth", does that hold for version 2.4 too? Version 3 was not available when we started our setup. You suggest, if I understand correctly: user -> SP -> Gluu's shibboleth -> Asimba -> many idps How and where precisely do we configure Gluu's shibboleth to forward to Asimba? We could not find this. (Keep in mind that we are not on 3.) If I look at the documentation, what you refer to seems written here as inbound saml, while we do SP initiated SSO. Are these the steps you suggest us to follow? https://gluu.org/docs/2.4.4/admin-guide/saml/#inbound-saml-asimba One use case is that certain claims we cannot fully trust a customer with. For example if they fake a different organization it is not acceptable that they can actually reach another (competing) customer in our system. There can also be also other data that we want to register on top of a certain IDP as we don't want to bother the customer with it. I also expect a need in the near future to embellish a small group of users with special properties we want to administer ourselves. Let us look into the saml_idp_attributes_mapping. The name of it sounds promising. Regards, Hugo

By Mohib Zico Account Admin 22 Feb 2017 at 2:37 a.m. CST

Mohib Zico gravatar
>> "All SP will be connected to your gluu server Shibboleth", does that hold for version 2.4 too? Yes. >> if I understand correctly: user -> SP -> Gluu's shibboleth -> Asimba -> many idps How and where precisely do we configure Gluu's shibboleth to forward to Asimba? IDPs are not connected with Gluu Server's Shibboleth but remote SPs are connected with Gluu-Shib. Gluu Server performs it's Asimba operations with it's own SAML Script ( named 'asimba' script aka. custom script) and Asimba configuration which are added [here](https://gluu.org/docs/admin-guide/saml/#inbound-saml-asimba) >> One use case is that certain claims we cannot fully trust a customer with. For example if they fake a different organization it is not acceptable that they can actually reach another (competing) customer in our system Ok. Yes, these custom requirements can be achieved with custom scripts.

By Hugo Brakman user 23 Feb 2017 at 5:46 a.m. CST

Hugo Brakman gravatar
Hi Mohib, We are setting up the configuration according to those instructions with Gluu's shibboleth and the interception "saml" script. However we face some difficulties with outdated versions of the instructions and such. We are now able to get to the login page of the idp via the interception script and then asimba. After that we face a number of issues: 1) The relay state seems to get "lost", we get redirected to the root folder of the webserver instead of /secure . Maybe related to this message in the logs "No 'ResponseLocation' found" from asimba. We need this in the asimba selector so just the redirect is not the only issue. 2) we pass (for one of the many SP) the relay state in plain text because we need to offer different IDPS in the selector.jsp of asimba based on the accessed url at the SP side. With gluu's shibboleth before asimba, the relay state is not passed so how can we get that back to filter the idps at asimba? 3) asimba_entity_id: this seems to require the id of the SP, but how can that work if we have many SP connecting to many IDP (via gluu shibboleth and then asimba)? 4) trying to log into the Gluu gui now redirects us to asimba so we cannot access the home page unless we disable the "saml" script, but then we still cannot use the gui because it gives this error: "Login failed, oxTrust wasn't allow to access user data ". In the logs there's this error: "[xdi.oxauth.authorize.ws.rs.AuthorizeAction] Failed to get CustomScriptConfigu" and "[org.gluu.oxtrust.action.Authenticator] No authorization code sent. Error: accequest." Perhaps a restart is needed but with only one working connection to the gui, we are not eager to do that. 5) claims are not properly passed back from the idp to the SP. Possibly due to this message in the log: "Can't trust AssertionConsumerServiceURL ". We don't get any claims on the SP side (only checking in the debug webpage itself), also not by other names. We would much appreciate pointers on how to overcome these issues as these are blocking the poc we are doing unfortunately. Regards, Hugo

By Mohib Zico Account Admin 23 Feb 2017 at 7:05 a.m. CST

Mohib Zico gravatar
Hi Hugo, I think I didn't understand #1 and #2; possible to clarify a bit? >> 3) asimba_entity_id: this seems to require the id of the SP, but how can that work if we have many SP connecting to many IDP (via gluu shibboleth and then asimba)? According to [doc](https://gluu.org/docs/admin-guide/saml/#inbound-saml-asimba), entityID is `https://test.gluu.org/saml`. It's not SP but it's the custom SP which is configured 'inside' your Gluu Server where Asimba is configured. >> 4) trying to log into the Gluu gui now redirects us to asimba so we cannot access the home page unless we disable the "saml" .... You need to put 'basic' as oxTrust authentication module from 'Manage Authentication' section. Seems like that part is missing in doc. >> 5) claims are not properly passed back from the idp to the SP. Possibly due to this message in the log: "Can't trust ... Can you get SAML assertion for Asimba; let's see what attributes it's releasing and what attributes we are planning to release.

By Hugo Brakman user 23 Feb 2017 at 7:33 a.m. CST

Hugo Brakman gravatar
Hi Mohib, "According to doc, entityID is https://test.gluu.org/saml. It's not SP but it's the custom SP which is configured 'inside' your Gluu Server where Asimba is configured. " Ah that makes sense again, thanks. "You need to put 'basic' as oxTrust authentication module from 'Manage Authentication' section. Seems like that part is missing in doc. " Right, we'll check that out. "Can you get SAML assertion for Asimba; let's see what attributes it's releasing and what attributes we are planning to release." Not sure how to do that precisely but I'll dig in the asimba part first. On point 1 and 2: When using the SPs -> Asimba -> IDPs configuration, the SPs would pass a relaystate request parameter to asimba that would identify the originally requested resource. E.g. webserver.com/page1. Several of our SPs we will map directly to a few IDPs. In those cases, in the selector.jsp of asimba, I can use the SAMLRequest parameter, make it readable, extract the SP and based on that I can filter the IDPs. Then we also have a few cases where an SP will map to IDPs based specifically on the exact requested resource. For example, webserver.com/page1 will map to IDP1 and IDPx while webserver.com/page2 will map to IDP2 and IDPx. This is where the problem lies: when using only asimba, I could configure the SP to pass the relay state in plain text. So it would pass "webserver.com/page1" to the asimba selector.jsp in the relaystate request parameter. When using Gluu shibboleth with interception script between the SP and Asimba, I do not have access to the relay state anymore in the selector.jsp. It is simply not passed through by Gluu shibboleth with interception. Do you know how we can configure it to pass this information through to Asimba? Then, based on it, I can filter the IDP list again. Regards, Hugo

By Hugo Brakman user 23 Feb 2017 at 7:43 a.m. CST

Hugo Brakman gravatar
btw, "You need to put 'basic' as oxTrust authentication module from 'Manage Authentication' section. Seems like that part is missing in doc. ", is that something we can do in some config file without the gui, as we cannot access the gui? Never mind this last question. It took a bit of crafting but with the help of the instructions here: https://gluu.org/docs/2.4.4/operation/faq/#revert-authentication-method we can access the gui again.

By Hao Bin Kwan Account Admin 24 Feb 2017 at 1:59 a.m. CST

Hao Bin Kwan gravatar
Hi Mohib, can you please share how 'custom sp' is setup 'inside' gluu server? ie. https://test.gluu.org/saml (which is used as asimba_entity_id in the custom script). - How do I generate the metadata of the custom sp? - Where do I add the custom sp in gluu server? eg. trust relationships and asimba's sp requestor? Appreciate your help here to get us moving forward. Thanks :)

By Mohib Zico Account Admin 24 Feb 2017 at 2:23 a.m. CST

Mohib Zico gravatar
>> How do I generate the metadata of the custom sp? >> Where do I add the custom sp in gluu server? eg. trust relationships and asimba's sp requestor? From doc.... "Add SP Requestor: .... Create a SAML metadata like below and save it as 'saml_oxauth_metadata.xml'. Upload this metadata."

By Hao Bin Kwan Account Admin 26 Feb 2017 at 9:21 p.m. CST

Hao Bin Kwan gravatar
Thanks Mohib. Finally I'm able to login successfully! Currently my flow is SP -> Gluu -(custom script)-> Asimba -> External IDP There is another problem now in getting attributes back (eg. username, mail etc) from external IDP (as nothing is returned). The wrapper log for Gluu with Asimba is as attached [http://pastebin.com/MVd76HXS](http://pastebin.com/MVd76HXS) P/s: I follow exactly the doc for inbound saml with custom script as provided above so the value for saml_idp_attributes_mapping is {"uid": ["uid", "urn:oid:0.9.2342.19200300.100.1.1"], "mail": ["mail", "urn:oid:0.9.2342.19200300.100.1.3"], "givenName": ["givenName", "urn:oid:2.5.4.42"], "sn": ["sn", "urn:oid:2.5.4.4"], "eduPersonPrincipalName": ["eduPersonPrincipalName", "urn:oid:1.3.6.1.4.1.5923.1.1.1.6"] } Thanks

By Mohib Zico Account Admin 27 Feb 2017 at 4 a.m. CST

Mohib Zico gravatar
Hi Hao, Thanks. Yes, seems like only UID is being released. Can you please share your 'asimba.xml' configuration file? >> P/s: I follow exactly the doc for inbound saml with custom script as provided above so the value for That's okay but I think you can just start with couple of attributes like UID, Email, GivenName. ePPN type attributes required some jobs there in Gluu Server side ( i.e. mapping attribute ).

By Hao Bin Kwan Account Admin 27 Feb 2017 at 4:05 a.m. CST

Hao Bin Kwan gravatar
Hi Mohib, Yeah I'd better start with getting some common attributes like what you mentioned above. But even if I specify ePPN in enforce_uniqueness_attr_list of custom script parameters I don't think it will cause any issue if there is no such attribute exist, pls correct me if I'm mistaken. Here is my asimba.xml: ``` <?xml version="1.0" encoding="UTF-8"?> <!-- * Asimba Server * * Copyright (C) 2012 Asimba * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU Affero General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Affero General Public License for more details. * * You should have received a copy of the GNU Affero General Public License * along with this program. If not, see www.gnu.org/licenses * * Asimba - Serious Open Source SSO - More information on www.asimba.org * --> <asimba-server> <!-- Server configuration --> <server id="gdc-shib-gluu2" friendlyname="Gluu Asimba Proxy"> <organization id="gdc-shib-gluu2" friendlyname="Gluu Asimba SSO"/> </server> <!-- Crypto configuration describes the behavior of the central cryptographic services and keystores that are used for protocol operations. There is a keystore that holds the cryptographic credentials (private- and public key and certificate) of the server itself as well as a truststore, that works as a placeholder for certificates of trusted entities For using SHA2 as signing algorithm, the value of signing algorithm should be "SHA256withRSA" --> <crypto> <message_digest algorithm="SHA1"/> <random_generator algorithm="SHA1PRNG" /> <signing algorithm="SHA1withRSA"> <signingfactory class="com.alfaariss.oa.engine.crypto.keystore.KeystoreSigningFactory"> <keystore> <file>/etc/certs/asimbaIDP.jks</file> <type>JKS</type> <keystore_password>sGDvQRAeFyeC</keystore_password> <alias>gdc-shib-gluu2</alias> <password>sGDvQRAeFyeC</password> </keystore> <!-- No truststore in baseline config yet; to enable the truststore, rename the 'no_truststore' element to 'truststore' --> <no_truststore> <file>${webapp.root}/WEB-INF/sample-data/asimba-demo-truststore.jks</file> <type>JKS</type> <keystore_password>changeit</keystore_password> </no_truststore> </signingfactory> </signing> </crypto> <!-- Configure sessionfactory implementation and behavior. The baseline server configures an in-memory session store. --> <sessionfactory class="com.alfaariss.oa.engine.session.memory.MemorySessionFactory"> <expire>900</expire> <interval>60</interval> <max>100</max> </sessionfactory> <!-- Configure the TicketGrantingTicket-factory implemententation and behavior. The baseline server configures an in-memory TGT store --> <tgtfactory class="com.alfaariss.oa.engine.tgt.memory.MemoryTGTFactory"> <expire>3600</expire> <interval>60</interval> <max>100</max> </tgtfactory> <!-- RequestorPoolFactory defines how requestors (sp's) are defined; they can be defined in this configuration file, but they can also be sourced from a table, available through a JDBC-connection (not in baseline config) A ResourcePool groups together the following attributes and behavior for a SP making a request: * the actual Requestor definitions * which authentication-profiles are available for a user * the attributerelease policy to apply * the pre- and post-authorization policy to apply * a property-list for each requestor * * LDAPFactory class: reads IDPs both from XML configuration and LDAP. --> <requestorpoolfactory class="org.gluu.asimba.engine.requestor.ldap.LDAPFactory"> <pool id="requestorpool.1" friendlyname="Requestor Pool 1" enabled="true"> <authentication forced="false"> <profile id="remote.saml2" /> </authentication> <!-- This configuration is for SP which will be connected with Asimba server. Add SP / protecte location in requestFactory section. * Requestor ID: It should be the entityID of SP * FriendlyName: It can be anything. Should be human readable. * enabled: true --> <requestors> <requestor id="http://sptest2.gluu.org/secure" friendlyname="Gluu Test SP" enabled="true" /> </requestors> <authorization> <post profile="postauthz.1" /> </authorization> <attributerelease policy="asimba.releasepolicy.1" /> </pool> </requestorpoolfactory> <!-- authentication: define Authentication Profiles; an AuthenticationProfile is made up of one or more authentication methods, which are executed sequentially. The behaviour of the actual authentication methods is defined in the websso section of the configuration --> <authentication class="com.alfaariss.oa.engine.authentication.configuration.ConfigurationFactory"> <profile id="remote.saml2" friendlyname="remote.saml2" enabled="true"> <method id="RemoteSAML" /> </profile> </authentication> <!-- websso: configure the behaviour of the server frontend. This is made up of * authentication: the authentication methods * profiles: the IDP profiles (SAML, A-Select, etc.) * postauthorization: the web postauthorization phase --> <websso> <authentication always_show_select_form="false"> <methods> <method id="RemoteSAML" friendlyname="Remote SAML authentication" enabled="true" response_signing_required="true" class="com.alfaariss.oa.authentication.remote.saml2.SAML2AuthenticationMethod"> <!-- Custom attribute will be configured here map ext == The source attribute ( i.e: uid, email etc) int == The name of custom attribute --> <attributemapper> <!-- <map ext="urn:oid:0.9.2342.19200300.100.1.1" int="$$CustomAttribute" /> --> </attributemapper> <!-- The SAML2 IDP Profile that services the ResponseEndpoint for the Remote SAML2 AuthenticationMethod, implementing a SAML2 SP --> <idpprofile id="saml2" /> <!-- When IDP could not be automatically selected, use a selector component to select an IDP --> <selector class="org.gluu.authentication.remote.saml2.selector.ApplicationSelectorLDAP" always_show_select_form="true" /> <!-- Indicate whether logout is supported by the SAML-SP profile --> <logout enabled="false" /> <authnstmt> <window before_offset="1800" after_offset="60" /> </authnstmt> <!-- <idps> configure the IDP's that this SAML-SP can use to request authentication. Configure remote IDP/ADFS which will do the authenticati on. * Download the metdata of remote IDP/ADFS and save it in some location with xml extension. * Grab the Base64 encoded SAML certificate of this IDP/ADFS and insert it in the JKS. Check �Work on keystore� in: http://www.gluu.org/docs/admin-guide/saml/inbound-saml/#asimba-configuration-with-gluu-server * idp id: It should be the entityID of remote IDP/ADFS * friendlyName: Anything human readable * scoping: false * avoid_subjectconfirmation: false * nameidpolicy enabled: false * �file�: Provide the absolute location of metadata * * IDPStorageLDAP class: reads IDPs both from XML configuration and LDAP. --> <idps id="saml2idps-chained" class="org.gluu.asimba.authentication.remote.saml2.idp.storage.ldap.IDPStorageLDAP"> <idp id="https://gdc-shib-gluu2/idp/shibboleth" friendlyname="Gluu Server CE" scoping="false" avoid_subjectconfirmation="false"> <nameidpolicy enabled="false" /> <metadata> <file>/opt/idp/metadata/16F18914E56A022B000178879B4D-idp-metadata.xml</file> </metadata> </idp> </idps> </method> </methods> </authentication> <postauthorization enabled="true"> <methods> <method id="AuthnContextToUserAttributesMethod" friendlyname="Add AuthenticationContext attributes to User attributes" class="org.asimba.custom.postauthz.authncontextattribute.AuthnContextToUserAttributes" enabled="true"> <attributes> <attribute authnmethod="RemoteSAML" src="issuer" dest="issuerIDP" required="true" /> </attributes> </method> </methods> </postauthorization> </websso> <!-- IDP Profiles. Configure the �baseURL� of Asimba Proxy server. Just add the hostname of your IDP. Rest of the URL will be same as it is by default. --> <profiles> <profile id="saml2" class="com.alfaariss.oa.profile.saml2.SAML2Profile"> <baseURL>https://gdc-shib-gluu2/asimba/profiles/saml2</baseURL> <websso path="/sso/web" /> <!-- requestors : configure the SAML-specific attributes of the requestors that have been declared in the requestorpoolfactory/requestors section When a requestor is not configured here, it is not considered to be a trusted SP Add metadata of remote SP requestor id: entityID of remote SP/protected location �file�: Absolute path of SP metadata. SAML2Profile reads both XML configuration and LDAP requestors. --> <requestors signing="FALSE"> <requestor id="http://sptest2.gluu.org/secure" signing="FALSE"> <metadata> <file>${webapp.root}/WEB-INF/sample-data/sptest2.xml</file> <!-- when metadata is sourced from a URL instead, the configuration could look like this: <http timeout="10000" url="http://my.serviceprovider.com/sp/metadata" /> --> </metadata> </requestor> </requestors> <!-- Issue Instant configuration; configures the timewindow for validating the timestamp of SAML messages; defaults to 60 seconds before- and after the local time Ensure that the clocks of all elements are synchronized in some way to a trusted time source! --> <IssueInstant> <window before_offset="60" after_offset="60" /> <!-- defaults --> </IssueInstant> <!-- Metadata configuration allows specific attributes of the SAML entity to be entered so they can be published as part of the metadata --> <metadata entityID="https://gdc-shib-gluu2/asimba/profiles/saml2"> <signing enabled="TRUE"/> <organization url="http://www.gluu.org"/> </metadata> <!-- Configure the SAML profiles, like SSO and Single Logout --> <profiles> <!-- SAML Profiles configuration --> <profile id="sso/web" class="com.alfaariss.oa.profile.saml2.profile.sso.WebBrowserSSO"> <!-- response: configure response settings response/expiration@offset :(optional) response expiration in seconds, defaults to 60 response/attributes@nameformat: (optional) specify the format in which attributes are returnes --> <response> <expiration offset="120" /> <attributes nameformat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" /> </response> <!-- authentication: configure for each Asimba AuthenticationProfile, the SAML2 AuthnContext value to return; i.e.: <authentication> <profile id="local.password" authncontext="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" /> </authentication> See: http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf --> <authentication> <profile id="local.guest" authncontext="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" /> <profile id="local.identifying" authncontext="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" /> <profile id="local.asimba.passwd" authncontext="urn:oasis:names:tc:SAML:2.0:ac:classes:Password" /> <profile id="local.sms.cm" authncontext="urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered" /> <profile id="local.pwdplussms" authncontext="urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered" /> </authentication> <bindings default="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" /> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"> <property name="path" value="/ui/profiles/saml2/http-post.jsp" /> </binding> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" > <property name="post" value="TRUE" /> <property name="path" value="/ui/profiles/saml2/http-artifact-post.jsp" /> </binding> </bindings> <nameid default="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"> <format id="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"> <!-- attribute@name: optional user attribute name that is used to build specified NameID format must be provided when setting opaque to be disabled --> <attribute name="email"/> <opaque enabled="FALSE" salt="0"/> </format> <format id="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"> <length>16</length> </format> <format id="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" /> <!-- <format id="urn:oasis:names:tc:SAML:1.1:nameid-format:email"> <attribute name="email"/> </format> --> <format id="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> <attribute name="email"/> </format> </nameid> </profile> <!-- sso/web --> <profile id="sso/logout" class="com.alfaariss.oa.profile.saml2.profile.sso.SingleLogout"> <bindings default="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" /> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"> <property name="path" value="/ui/profiles/saml2/http-post.jsp" /> </binding> <!-- <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" > <property name="post" value="false" /> <property name="path" value="/ui/profiles/saml2/http-artifact-post.jsp" /> </binding> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" /> --> </bindings> <nameid> <format id="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"> <attribute name="email"/> <opaque enabled="FALSE" salt="0"/> </format> <format id="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"> <length>16</length> </format> <format id="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" /> <!-- dopey adds: --> <!-- <format id="urn:oasis:names:tc:SAML:1.1:nameid-format:email"> <attribute name="email"/> </format> --> <!-- dopey adds until here --> <format id="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> <attribute name="email"/> </format> </nameid> </profile> <!-- sso/logout --> <!-- SAML Profiles configuration --> <profile id="sp/sso/web" class="com.alfaariss.oa.authentication.remote.saml2.profile.re.ResponseEndpoint"> <signing authnRequestsSigned="true" wantAssertionsSigned="true" /> <bindings default="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"> <property name="path" value="/ui/profiles/saml2/http-post.jsp" /> </binding> <binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"> <property name="post" value="false" /> <property name="path" value="/ui/profiles/saml2/http-artifact-post.jsp" /> </binding> </bindings> </profile> <!-- sp/sso/web --> </profiles> </profile> </profiles> <attributegatherer id="asimba.gatherer.1" friendlyname="Collect attributes from all sources" enabled="true"> <processor id="AsimbaUsersXml" friendlyname="Source asimba-users.xml" class="org.asimba.engine.attribute.gather.processor.file.AsimbaUsersXmlGatherer"> <file>${webapp.root}/WEB-INF/sample-data/asimba-users.xml</file> <!-- gather can specify a whitelist of attributes to gather if omitted, all available attributes are gathered --> <!-- <gather> <attribute name="whitelist-attribute-name" /> </gather> --> <mapper> <map ext="ext.phonenr" int="phonenr" /> </mapper> </processor> </attributegatherer> <attributerelease class="com.alfaariss.oa.engine.attribute.release.configuration.ConfigurationFactory"> <policy id="asimba.releasepolicy.1" friendlyname="Default Attribute Release policy" enabled="true"> <attribute name="firstname" /> <attribute name="lastname" /> <attribute name="email" /> <attribute name="role" /> <attribute name="country" /> <!-- country is defined in <global ..> attribute section --> <!-- when all available attributes can be released, use the wildcard "*" for name, like: <attribute name="*" /> Asimba Baseline keeps the password in the same format as the attributes, so allowing all attributes to be released, would expose the password as well! --> <attribute name="*" /> </policy> </attributerelease> <!-- <postauthorization> defines which profiles are available in this server instance --> <postauthorization class="com.alfaariss.oa.engine.authorization.configuration.ConfigurationFactory" enabled="true"> <profile id="postauthz.1" friendlyname="Default PostAuthorization Profile" enabled="true"> <method id="AuthnContextToUserAttributesMethod" /> </profile> </postauthorization> <!-- Helpers --> <helpers> <helper id="stylesheet" enabled="true" class="com.alfaariss.oa.helper.stylesheet.StyleSheetHelper" /> </helpers> </asimba-server> ```

By Mohib Zico Account Admin 27 Feb 2017 at 8:24 a.m. CST

Mohib Zico gravatar
>> pls correct me if I'm mistaken. Yes, you are correct. In asimba.xml file let's uncomment below snippet and restart tomcat. Let's see how it goes now... ``` <!-- <gather> <attribute name="whitelist-attribute-name" /> </gather> --> ```

By Hao Bin Kwan Account Admin 28 Feb 2017 at 1:45 a.m. CST

Hao Bin Kwan gravatar
Nice one Mohib, at least now I can get uid (UserName) returned, although it's in the form of multivalued (as it is imported from external ldap 'enroll' method in the script) [UserName] => !testqod5!!;testqod5 Few questions for asimba whitelist-attribute-name: 1. Can you briefly explain how does this work and how do I get more attributes from IDP? (eg. mail, displayname, department, etc) 2. Right now I configured asimba and sp in trust relationship to release all of the attributes I wish to retrieve so is there anywhere else I need to change? 3. I've also attached the log (from asimba to login to external idp): [http://pastebin.com/sEQvvTn0](http://pastebin.com/sEQvvTn0) for your reference. Thanks

By William Lowe user 28 Feb 2017 at 9:27 a.m. CST

William Lowe gravatar
Hey Hao, I would encourage you to open new tickets as the topic of discussion changes. When tickets get long and jump from question to question it becomes difficult for us to track them. I'm going to close this ticket. Can you please open a new focused ticket with your above questions?