SSO Attribute syntax

I have basic authentication using SAML working fine with WSO2. Although I can authenticate using the custom SSO provider, I haven't found documentation on how to map attributes from the Identity Provider back to Knack.

basically, I need to know what Knack would expect for the:

<saml:AttributeStatement>
<saml:Attribute>
?????
<saml:AttributeValue>
</saml:AttributeValue>
</saml:AttributeValue>

I understand the the attributes and names will be app dependent but I would like to know what I refer to in the app to match the attributes. Do I use the name of the Knack field as defined in my app? For example if I have a field named "Current Age" is that what the Attribute Name should be? Any qualifiers to the name (app name, for instance?) I am new to SSO and SAML so I am guessing that is the way it should be but I just want to make sure...

Thanks

What identify provider are you guys using? And what login system? I am so lost on this SSO stuff I wish there was better documentation for it.

Sorry, I think I misunderstood your problem. I worked out how to get the basic user details into Knack during SSO with auto-registration. The full SAML attribute names have to match with the associated "Property" fields in the SAML settings (which was not real clear from the documentation or the GUI). I thought you were suggesting even this couldn't be done.

Is this really correct? I'm trying to get this working at the moment and from the user interface it seems like I should be able to pass 4 attributes from the IdP. From the terminology of "eduPersonTargetedID" it seems they are using Shibboleth. A sample working assertion would be nice.

So, the answer here is basically, I can't do it this way. Knack currently doesn't support the parsing of the returned attributes even if my Identity Server returned them. Authentication is binary (it authenticates or it doesn't) and authorization is basically handled by a successful authentication to a page. What ever page the login was authenticating carries the role(s) for the authenticated user.

So I am looking at alternative approaches.