[OpenAM] Assertion without User Profile

[Major Péter]

Hi,

the basic functions should work with the datastore I think, you only 
going to have problems if you start mapping things around or want to use 
groupmanagement I think.
No need for prefix, it should work out of the box.

Regards,
Peter

On 2011-03-04 12:24, Erik Langnes wrote:
> Hi,
> thanks for your quick reply. I will try this, and hopefully one of the
> session attributes has what I'm looking for.
> It appears to me, at the moment, that the JDBC datastore seems to work
> just fine, but in a production environment I'd feel better running on
> something that is not "Early Access" and "bit buggy".
> However, to do that I must fix the attribute mapping, which I might be
> very close to do now, then.
>
> So... let's say that I find in the debug session data contains a key
> "username" with the value of the user's username..
> Do I change the attribute mapper to be "uid=username", or do I have to
> prefix the session attributes somehow to differentiate from profile
> attributes?
>
> Thanks!
>
> Erik
>
>
> 2011/3/4 Major Péter<majorpetya at sch.bme.hu <mailto:majorpetya at sch.bme.hu>>
>
>     Hi,
>
>     the built-in attribute mapper tries to map profile and session
>     attributes to the assertion, and the profile attributes are coming from
>     the datastore. Maybe one of the basic session attributes fits your
>     needs, so what you should do first, is to enable message level debugging
>     and log out with a random user. When a user logs out all of his session
>     attributes are logged in to the Session debug log on message level. This
>     way you can check whether you have a suitable session attribute or not.
>     If this is a dead-end, then IMHO you can write an own attribute mapper,
>     which can go to the database with JDBC and ask the attributes about the
>     logged in user.
>     //or you can try out the bit buggy JDBC datastore..
>
>     Regards,
>     Peter
>
>     On 2011-03-04 12:00, Erik Langnes wrote:
>     >  Hi,
>     >  I have set up an OpenAM-installation as a SAML 2.0 IDP which I want to
>     >  use for authentication for a series of separate web-applications.
>     >  My requirement is that the IDP verifies credentials (username and
>     >  password) and, upon successful authentication, returns a SAMLResponse
>     >  with an assertion containing the username as a field "uid".
>     >  This way the SP, which initiated the SSO by issuing a
>     AuthnRequest, will
>     >  know the actual user's id upon successful authentication and could use
>     >  this information to fetch user-specific data and/or perform
>     >  authorization. This is quite a common scenario, I believe, and I
>     have it
>     >  up and running using a single Data Store with User Profile Requirement
>     >  set to "Required". This works fine when configuring the attribute
>     mapper
>     >  under Assertion Processing for each SP (uid=uid).
>     >
>     >  This is all good, but the thing is that the usernames and
>     passwords are
>     >  stored in an SQL database. Therefore I find the JDBC authentication
>     >  module to be the most fitting for the job of verifying user's
>     >  credentials. As I do not require anything more than this, I also
>     do not
>     >  require a Data Store for these users. Setting the user profile
>     >  requirement to "Ignore" allows for this, and still issues a SSO Token
>     >  for the authenticated user. However, when setting up the system
>     this way
>     >  the assertion returned to the Service Provider does no longer contain
>     >  the uid-attribute, as it did when using a Data Store for
>     authentication.
>     >
>     >  My question is; is it possible to set up a realm with one
>     authentication
>     >  module (JDBC) with no user profile requirement (Ignore) and in the
>     >  Assertion in the SAMLResponse to the AuthnRequest include the user's
>     >  username? If so how - it seems like the attribute mapper does not
>     match
>     >  uid anymore with this setup?
>     >
>     >  Thanks!
>     >
>     >  Erik
>     >
>     >  Btw:
>     >  Thanks to you who answered my previous mail late last year!