openam post authentication plugin

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

openam post authentication plugin

Brett @Google
Hello,

When writing a post authentication plugin, what is the best way to do ad-hoc ldap searches ?

Intent is to search for information in ldap, as a basis to set properties in the user session :

@SuppressWarnings("rawtypes")
public void onLoginSuccess(Map requestParamsMap, HttpServletRequest request,
    HttpServletResponse response, SSOToken token) throws AuthenticationException {
    List<String> allowedGroups = null;
    String principalName = null;
    try {
        principalName = token.getPrincipal().getName();
        allowedGroups = getAllowedGroups(token.getPrincipal());
        token.setProperty(ALLOWED_GROUPS_KEY, getAllowedGroupsAsString(allowedGroups));
    } catch (SSOException ssoe) {
        debug.error("Unable to set property allowedGroups="+getAllowedGroupsAsString(allowedGroups)+" for "+principalName);
    }       
}

In this example, the items are simple strings that represent things of importance in user land, which apps might use to allow things that the user may do, it might be groups they are part of, or more mundane matters, as real name, so that the app can display that more easily.

I'm assuming in this example, the getAllowedGroups will search ldap, and return a simple text-ified array of things about the user, in this example maybe user-meaningful group names (perhaps loosely based on groups that the user is a member of, with some business logic applied), that only really means something to the application which the user authenticates.

This will be used lightly, but intent is to avoid unnecessary LDAP lookups in the web interface authenticating to openam, if not required, but decorate the user session with details from LDAP that will be globally useful, in a way that is not possible by openam directly.

My first problem seems to be getting the ldap configuration to the post auth plugin:

Options include LDAP using JNDI directly, but then i need to specify the LDAP configuration details. Even if i use JNDI directly, it would be nice to be able to re-use the openam ldap configuration. Optimally, it would be nice to use openam's pre-existing LDAP code for ad-hoc searches, and not have to manage JNDI directly.

Cheers
Brett

--
Whenever you find yourself on the side of the majority, it is time to pause and reflect.

- Mark Twain

_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openam post authentication plugin

Allan Foster
Have a look at the Adaptive Auth module.

It does exactly what you want.  Make sure that you use the right User ID

Allan

Simplify Email: Email Charter

ForgeRock Logo Allan Foster - ForgeRock
Vice President Technology & Standards
Office of the CTO
Location: Vancouver, WA, US
p: +1.360.229.7102
email: [hidden email]
www: www.forgerock.com
www: www.forgerock.org
blogs: blogs.forgerock.com/GuruAllan
On 4/22/14, 6:11 PM, Brett @Google wrote:
Hello,

When writing a post authentication plugin, what is the best way to do ad-hoc ldap searches ?

Intent is to search for information in ldap, as a basis to set properties in the user session :

@SuppressWarnings("rawtypes")
public void onLoginSuccess(Map requestParamsMap, HttpServletRequest request,
    HttpServletResponse response, SSOToken token) throws AuthenticationException {
    List<String> allowedGroups = null;
    String principalName = null;
    try {
        principalName = token.getPrincipal().getName();
        allowedGroups = getAllowedGroups(token.getPrincipal());
        token.setProperty(ALLOWED_GROUPS_KEY, getAllowedGroupsAsString(allowedGroups));
    } catch (SSOException ssoe) {
        debug.error("Unable to set property allowedGroups="+getAllowedGroupsAsString(allowedGroups)+" for "+principalName);
    }       
}

In this example, the items are simple strings that represent things of importance in user land, which apps might use to allow things that the user may do, it might be groups they are part of, or more mundane matters, as real name, so that the app can display that more easily.

I'm assuming in this example, the getAllowedGroups will search ldap, and return a simple text-ified array of things about the user, in this example maybe user-meaningful group names (perhaps loosely based on groups that the user is a member of, with some business logic applied), that only really means something to the application which the user authenticates.

This will be used lightly, but intent is to avoid unnecessary LDAP lookups in the web interface authenticating to openam, if not required, but decorate the user session with details from LDAP that will be globally useful, in a way that is not possible by openam directly.

My first problem seems to be getting the ldap configuration to the post auth plugin:

Options include LDAP using JNDI directly, but then i need to specify the LDAP configuration details. Even if i use JNDI directly, it would be nice to be able to re-use the openam ldap configuration. Optimally, it would be nice to use openam's pre-existing LDAP code for ad-hoc searches, and not have to manage JNDI directly.

Cheers
Brett

--
Whenever you find yourself on the side of the majority, it is time to pause and reflect.

- Mark Twain


_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam


_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openam post authentication plugin

Peter Major
In reply to this post by Brett @Google
Hi,

when storing stuff in the session you should understand that:
* you are increasing the size of session by adding properties to it, be
clear on what this may mean when it comes to sizing your deployment.
* While this mechanism looks great first, you'll figure later that this
isn't too flexible: the properties will stay there even after the
underlying data has been changed.

If this is something for an application then you could also attempt to
write a Policy Response Provider that could cache the results, so you
have a better chance at retrieving up-to-date data (especially when the
session has long timeout).

To retrieve the actual data you have two chance:
* use the IdRepo API suggested by Allan earlier, but this only works if
the underlying data store can return all the necessary bits (e.g. you
don't have to query completely different directories for extra details)
* use DJ SDK (included in AM for a while now) code. For the connection
details yes, you could go fancy and retrieve them from the configuration
store, but that would be quite advanced and a painful experience most
likely (the SMS code isn't too nice).

cheers,
Peter

2014.04.23. 2:11 keltezéssel, Brett @Google írta:

> Hello,
>
> When writing a post authentication plugin, what is the best way to do
> ad-hoc ldap searches ?
>
> Intent is to search for information in ldap, as a basis to set
> properties in the user session :
>
> @SuppressWarnings("rawtypes")
> public void onLoginSuccess(Map requestParamsMap, HttpServletRequest request,
>      HttpServletResponse response, SSOToken token) throws
> AuthenticationException {
>      List<String> allowedGroups = null;
>      String principalName = null;
>      try {
>          principalName = token.getPrincipal().getName();
>          allowedGroups = getAllowedGroups(token.getPrincipal());
>          token.setProperty(ALLOWED_GROUPS_KEY,
> getAllowedGroupsAsString(allowedGroups));
>      } catch (SSOException ssoe) {
>          debug.error("Unable to set property
> allowedGroups="+getAllowedGroupsAsString(allowedGroups)+" for
> "+principalName);
>      }
> }
>
> In this example, the items are simple strings that represent things of
> importance in user land, which apps might use to allow things that the
> user may do, it might be groups they are part of, or more mundane
> matters, as real name, so that the app can display that more easily.
>
> I'm assuming in this example, the getAllowedGroups will search ldap, and
> return a simple text-ified array of things about the user, in this
> example maybe user-meaningful group names (perhaps loosely based on
> groups that the user is a member of, with some business logic applied),
> that only really means something to the application which the user
> authenticates.
>
> This will be used lightly, but intent is to avoid unnecessary LDAP
> lookups in the web interface authenticating to openam, if not required,
> but decorate the user session with details from LDAP that will be
> globally useful, in a way that is not possible by openam directly.
>
> My first problem seems to be getting the ldap configuration to the post
> auth plugin:
>
> Options include LDAP using JNDI directly, but then i need to specify the
> LDAP configuration details. Even if i use JNDI directly, it would be
> nice to be able to re-use the openam ldap configuration. Optimally, it
> would be nice to use openam's pre-existing LDAP code for ad-hoc
> searches, and not have to manage JNDI directly.
>
> Cheers
> Brett
>
> --
> Whenever you find yourself on the side of the majority, it is time to
> pause and reflect.
>
> - Mark Twain
>
>
> _______________________________________________
> OpenAM mailing list
> [hidden email]
> https://lists.forgerock.org/mailman/listinfo/openam
>
_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openam post authentication plugin

Kolev, Ivo
In reply to this post by Allan Foster

Another option could be to setup a dummy auth module which injects LDAP configuration into session user properties. This way you get an UI to manage the configuration through OpenAM. The config arrives as map2 of module init(). You could bind the config as user properties calling super.setUserSessionProperty(KEY_LDAP_URL, theValueFromMap2);

 

Cheers, Ivo Kolev

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Allan Foster
Sent: Wednesday, April 23, 2014 4:34 AM
To: [hidden email]; [hidden email]
Subject: Re: [OpenAM] openam post authentication plugin

 

Have a look at the Adaptive Auth module.

It does exactly what you want.  Make sure that you use the right User ID

Allan

Simplify Email: Email Charter

ForgeRock Logo

Allan Foster - ForgeRock
Vice President Technology & Standards
Office of the CTO
Location: Vancouver, WA, US
p: +1.360.229.7102

email: [hidden email]
www: www.forgerock.com
www: www.forgerock.org
blogs: blogs.forgerock.com/GuruAllan

On 4/22/14, 6:11 PM, Brett @Google wrote:

Hello,

When writing a post authentication plugin, what is the best way to do ad-hoc ldap searches ?

Intent is to search for information in ldap, as a basis to set properties in the user session :


@SuppressWarnings("rawtypes")
public void onLoginSuccess(Map requestParamsMap, HttpServletRequest request,
    HttpServletResponse response, SSOToken token) throws AuthenticationException {
    List<String> allowedGroups = null;
    String principalName = null;
    try {
        principalName = token.getPrincipal().getName();
        allowedGroups = getAllowedGroups(token.getPrincipal());
        token.setProperty(ALLOWED_GROUPS_KEY, getAllowedGroupsAsString(allowedGroups));
    } catch (SSOException ssoe) {
        debug.error("Unable to set property allowedGroups="+getAllowedGroupsAsString(allowedGroups)+" for "+principalName);
    }       
}

In this example, the items are simple strings that represent things of importance in user land, which apps might use to allow things that the user may do, it might be groups they are part of, or more mundane matters, as real name, so that the app can display that more easily.

 

I'm assuming in this example, the getAllowedGroups will search ldap, and return a simple text-ified array of things about the user, in this example maybe user-meaningful group names (perhaps loosely based on groups that the user is a member of, with some business logic applied), that only really means something to the application which the user authenticates.

This will be used lightly, but intent is to avoid unnecessary LDAP lookups in the web interface authenticating to openam, if not required, but decorate the user session with details from LDAP that will be globally useful, in a way that is not possible by openam directly.

My first problem seems to be getting the ldap configuration to the post auth plugin:

Options include LDAP using JNDI directly, but then i need to specify the LDAP configuration details. Even if i use JNDI directly, it would be nice to be able to re-use the openam ldap configuration. Optimally, it would be nice to use openam's pre-existing LDAP code for ad-hoc searches, and not have to manage JNDI directly.

 

Cheers

Brett


--
Whenever you find yourself on the side of the majority, it is time to pause and reflect.

- Mark Twain




_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

 


Information in this e-mail and any attachments is confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient. Although Experian has taken reasonable steps to ensure that this communication and any attachments are free from computer viruses, you are advised to take your own steps to ensure that they are actually virus free.

Experian Ltd is authorised and regulated by the Financial Conduct Authority.
Companies Act information: Registered name: Experian Limited. Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, NG80 1ZZ, United Kingdom. Place of registration: England and Wales. Registered number: 653331.

_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openam post authentication plugin

Peter Major
That's a horrible thing to do. Having internal credentials stored in a
user session sounds like a REALLY BAD IDEA.

2014.04.23. 9:20 keltezéssel, Kolev, Ivo írta:

> Another option could be to setup a dummy auth module which injects LDAP
> configuration into session user properties. This way you get an UI to
> manage the configuration through OpenAM. The config arrives as map2 of
> module init(). You could bind the config as user properties calling
> super.setUserSessionProperty(KEY_LDAP_URL, theValueFromMap2);
>
> Cheers, Ivo Kolev
>
> *From:*[hidden email]
> [mailto:[hidden email]] *On Behalf Of *Allan Foster
> *Sent:* Wednesday, April 23, 2014 4:34 AM
> *To:* [hidden email]; [hidden email]
> *Subject:* Re: [OpenAM] openam post authentication plugin
>
> Have a look at the Adaptive Auth module.
>
> It does exactly what you want.  Make sure that you use the right User ID
>
> Allan
>
> Simplify Email: Email Charter <http://emailcharter.org/>
>
> ForgeRock Logo
>
>
>
> *Allan Foster - ForgeRock *
> /Vice President Technology & Standards/
> *Office of the CTO*
> *Location:* Vancouver, WA, US
> *p:* +1.360.229.7102
>
> *email:* [hidden email] <mailto:[hidden email]>
> *www:* www.forgerock.com <http://www.forgerock.com/>
> *www:* www.forgerock.org <http://www.forgerock.org/>
> *blogs:* blogs.forgerock.com/GuruAllan
> <http://blogs.forgerock.com/GuruAllan>
>
> On 4/22/14, 6:11 PM, Brett @Google wrote:
>
>     Hello,
>
>     When writing a post authentication plugin, what is the best way to
>     do ad-hoc ldap searches ?
>
>     Intent is to search for information in ldap, as a basis to set
>     properties in the user session :
>
>
>     @SuppressWarnings("rawtypes")
>     public void onLoginSuccess(Map requestParamsMap, HttpServletRequest
>     request,
>          HttpServletResponse response, SSOToken token) throws
>     AuthenticationException {
>          List<String> allowedGroups = null;
>          String principalName = null;
>          try {
>              principalName = token.getPrincipal().getName();
>              allowedGroups = getAllowedGroups(token.getPrincipal());
>              token.setProperty(ALLOWED_GROUPS_KEY,
>     getAllowedGroupsAsString(allowedGroups));
>          } catch (SSOException ssoe) {
>              debug.error("Unable to set property
>     allowedGroups="+getAllowedGroupsAsString(allowedGroups)+" for
>     "+principalName);
>          }
>     }
>
>     In this example, the items are simple strings that represent things
>     of importance in user land, which apps might use to allow things
>     that the user may do, it might be groups they are part of, or more
>     mundane matters, as real name, so that the app can display that more
>     easily.
>
>     I'm assuming in this example, the getAllowedGroups will search ldap,
>     and return a simple text-ified array of things about the user, in
>     this example maybe user-meaningful group names (perhaps loosely
>     based on groups that the user is a member of, with some business
>     logic applied), that only really means something to the application
>     which the user authenticates.
>
>     This will be used lightly, but intent is to avoid unnecessary LDAP
>     lookups in the web interface authenticating to openam, if not
>     required, but decorate the user session with details from LDAP that
>     will be globally useful, in a way that is not possible by openam
>     directly.
>
>     My first problem seems to be getting the ldap configuration to the
>     post auth plugin:
>
>     Options include LDAP using JNDI directly, but then i need to specify
>     the LDAP configuration details. Even if i use JNDI directly, it
>     would be nice to be able to re-use the openam ldap configuration.
>     Optimally, it would be nice to use openam's pre-existing LDAP code
>     for ad-hoc searches, and not have to manage JNDI directly.
>
>     Cheers
>
>     Brett
>
>
>     --
>     Whenever you find yourself on the side of the majority, it is time
>     to pause and reflect.
>
>     - Mark Twain
>
>
>
>
>     _______________________________________________
>
>     OpenAM mailing list
>
>     [hidden email]  <mailto:[hidden email]>
>
>     https://lists.forgerock.org/mailman/listinfo/openam
>
>
> Information in this e-mail and any attachments is confidential, and may
> not be copied or used by anyone other than the addressee, nor disclosed
> to any third party without our permission. There is no intention to
> create any legally binding contract or other binding commitment through
> the use of this electronic communication unless it is issued in
> accordance with the Experian Limited standard terms and conditions of
> purchase or other express written agreement between Experian Limited and
> the recipient. Although Experian has taken reasonable steps to ensure
> that this communication and any attachments are free from computer
> viruses, you are advised to take your own steps to ensure that they are
> actually virus free.
>
> Experian Ltd is authorised and regulated by the Financial Conduct Authority.
> Companies Act information: Registered name: Experian Limited. Registered
> office: Landmark House, Experian Way, NG2 Business Park, Nottingham,
> NG80 1ZZ, United Kingdom. Place of registration: England and Wales.
> Registered number: 653331.
>
>
> _______________________________________________
> OpenAM mailing list
> [hidden email]
> https://lists.forgerock.org/mailman/listinfo/openam
>
_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openam post authentication plugin

Kolev, Ivo
I agree, this is a security vulnerability if the credentials stay in the token. But these could be reset in the post auth plugin. Though the question then is why not retrieving groups in the auth module directly.

Anyway, the provisining through some policy(?) provider should be the right approach.

Cheers, Ivo
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter Major
Sent: Wednesday, April 23, 2014 11:22 AM
To: Users
Subject: Re: [OpenAM] openam post authentication plugin

That's a horrible thing to do. Having internal credentials stored in a user session sounds like a REALLY BAD IDEA.

2014.04.23. 9:20 keltezéssel, Kolev, Ivo írta:
> Another option could be to setup a dummy auth module which injects
> LDAP configuration into session user properties. This way you get an
> UI to manage the configuration through OpenAM. The config arrives as
> map2 of module init(). You could bind the config as user properties
> calling super.setUserSessionProperty(KEY_LDAP_URL, theValueFromMap2);
>
> Cheers, Ivo Kolev
>

Information in this e-mail and any attachments is confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient. Although Experian has taken reasonable steps to ensure that this communication and any attachments are free from computer viruses, you are advised to take your own steps to ensure that they are actually virus free.

Experian Ltd is authorised and regulated by the Financial Conduct Authority.
Companies Act information: Registered name: Experian Limited. Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, NG80 1ZZ, United Kingdom. Place of registration: England and Wales. Registered number: 653331.
_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openam post authentication plugin

Brett @Google
In reply to this post by Peter Major
But doing a search again is a little overhead, but the LDAP config has to be specified for the post auth plugin also.

Things like storing the user's DN (or unique key such as entryUUID etc.,) in the session might be useful, as it would save a search later, in the post authentication plugin. It's probably better to refresh the data if it's likely to change. But I was thinking about things like full name or org unit, these are cosmetic things that are pretty small, and wont change often.

Is there a simple mechanism for the post auth plugin to retrieve name=value configurables from the openidm UI ?

Or failing that, a parameter somewhere, that just gives the name for a config file for the (post auth) ldap settings ?



On Wed, Apr 23, 2014 at 5:09 PM, Peter Major <[hidden email]> wrote:
Hi,

when storing stuff in the session you should understand that:
* you are increasing the size of session by adding properties to it, be clear on what this may mean when it comes to sizing your deployment.
* While this mechanism looks great first, you'll figure later that this isn't too flexible: the properties will stay there even after the underlying data has been changed.

If this is something for an application then you could also attempt to write a Policy Response Provider that could cache the results, so you have a better chance at retrieving up-to-date data (especially when the session has long timeout).

To retrieve the actual data you have two chance:
* use the IdRepo API suggested by Allan earlier, but this only works if the underlying data store can return all the necessary bits (e.g. you don't have to query completely different directories for extra details)
* use DJ SDK (included in AM for a while now) code. For the connection details yes, you could go fancy and retrieve them from the configuration store, but that would be quite advanced and a painful experience most likely (the SMS code isn't too nice).

cheers,
Peter

2014.04.23. 2:11 keltezéssel, Brett @Google írta:
Hello,

When writing a post authentication plugin, what is the best way to do
ad-hoc ldap searches ?

Intent is to search for information in ldap, as a basis to set
properties in the user session :

@SuppressWarnings("rawtypes")
public void onLoginSuccess(Map requestParamsMap, HttpServletRequest request,
     HttpServletResponse response, SSOToken token) throws
AuthenticationException {
     List<String> allowedGroups = null;
     String principalName = null;
     try {
         principalName = token.getPrincipal().getName();
         allowedGroups = getAllowedGroups(token.getPrincipal());
         token.setProperty(ALLOWED_GROUPS_KEY,
getAllowedGroupsAsString(allowedGroups));
     } catch (SSOException ssoe) {
         debug.error("Unable to set property
allowedGroups="+getAllowedGroupsAsString(allowedGroups)+" for
"+principalName);
     }
}

In this example, the items are simple strings that represent things of
importance in user land, which apps might use to allow things that the
user may do, it might be groups they are part of, or more mundane
matters, as real name, so that the app can display that more easily.

I'm assuming in this example, the getAllowedGroups will search ldap, and
return a simple text-ified array of things about the user, in this
example maybe user-meaningful group names (perhaps loosely based on
groups that the user is a member of, with some business logic applied),
that only really means something to the application which the user
authenticates.

This will be used lightly, but intent is to avoid unnecessary LDAP
lookups in the web interface authenticating to openam, if not required,
but decorate the user session with details from LDAP that will be
globally useful, in a way that is not possible by openam directly.

My first problem seems to be getting the ldap configuration to the post
auth plugin:

Options include LDAP using JNDI directly, but then i need to specify the
LDAP configuration details. Even if i use JNDI directly, it would be
nice to be able to re-use the openam ldap configuration. Optimally, it
would be nice to use openam's pre-existing LDAP code for ad-hoc
searches, and not have to manage JNDI directly.

Cheers
Brett

--
Whenever you find yourself on the side of the majority, it is time to
pause and reflect.

- Mark Twain


_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



--
Whenever you find yourself on the side of the majority, it is time to pause and reflect.

- Mark Twain

_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openam post authentication plugin

Peter Major
> Things like storing the user's DN (or unique key such as entryUUID
> etc.,) in the session might be useful, as it would save a search later,
> in the post authentication plugin. It's probably better to refresh the
> data if it's likely to change. But I was thinking about things like full
> name or org unit, these are cosmetic things that are pretty small, and
> wont change often.

still, if it changes it will remain stale until there is a new session.
You should check out the "mapping profile attributes to session
properties" setting under Access Control - realm - Authentication - All
core settings, that may be sufficient already.

> Is there a simple mechanism for the post auth plugin to retrieve
> name=value configurables from the openidm UI ?

pretty sure there is no such integration just yet.

> Or failing that, a parameter somewhere, that just gives the name for a
> config file for the (post auth) ldap settings ?

There are no config files used in OpenAM, almost everything is stored in
the configuration store (so LDAP again). You could use the SMS API for
that, but it will be a bit complex...

cheers,
Peter

> On Wed, Apr 23, 2014 at 5:09 PM, Peter Major <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     when storing stuff in the session you should understand that:
>     * you are increasing the size of session by adding properties to it,
>     be clear on what this may mean when it comes to sizing your deployment.
>     * While this mechanism looks great first, you'll figure later that
>     this isn't too flexible: the properties will stay there even after
>     the underlying data has been changed.
>
>     If this is something for an application then you could also attempt
>     to write a Policy Response Provider that could cache the results, so
>     you have a better chance at retrieving up-to-date data (especially
>     when the session has long timeout).
>
>     To retrieve the actual data you have two chance:
>     * use the IdRepo API suggested by Allan earlier, but this only works
>     if the underlying data store can return all the necessary bits (e.g.
>     you don't have to query completely different directories for extra
>     details)
>     * use DJ SDK (included in AM for a while now) code. For the
>     connection details yes, you could go fancy and retrieve them from
>     the configuration store, but that would be quite advanced and a
>     painful experience most likely (the SMS code isn't too nice).
>
>     cheers,
>     Peter
>
>     2014.04.23. 2:11 keltezéssel, Brett @Google írta:
>
>         Hello,
>
>         When writing a post authentication plugin, what is the best way
>         to do
>         ad-hoc ldap searches ?
>
>         Intent is to search for information in ldap, as a basis to set
>         properties in the user session :
>
>         @SuppressWarnings("rawtypes")
>         public void onLoginSuccess(Map requestParamsMap,
>         HttpServletRequest request,
>               HttpServletResponse response, SSOToken token) throws
>         AuthenticationException {
>               List<String> allowedGroups = null;
>               String principalName = null;
>               try {
>                   principalName = token.getPrincipal().getName()__;
>                   allowedGroups = getAllowedGroups(token.__getPrincipal());
>                   token.setProperty(ALLOWED___GROUPS_KEY,
>         getAllowedGroupsAsString(__allowedGroups));
>               } catch (SSOException ssoe) {
>                   debug.error("Unable to set property
>         allowedGroups="+__getAllowedGroupsAsString(__allowedGroups)+" for
>         "+principalName);
>               }
>         }
>
>         In this example, the items are simple strings that represent
>         things of
>         importance in user land, which apps might use to allow things
>         that the
>         user may do, it might be groups they are part of, or more mundane
>         matters, as real name, so that the app can display that more easily.
>
>         I'm assuming in this example, the getAllowedGroups will search
>         ldap, and
>         return a simple text-ified array of things about the user, in this
>         example maybe user-meaningful group names (perhaps loosely based on
>         groups that the user is a member of, with some business logic
>         applied),
>         that only really means something to the application which the user
>         authenticates.
>
>         This will be used lightly, but intent is to avoid unnecessary LDAP
>         lookups in the web interface authenticating to openam, if not
>         required,
>         but decorate the user session with details from LDAP that will be
>         globally useful, in a way that is not possible by openam directly.
>
>         My first problem seems to be getting the ldap configuration to
>         the post
>         auth plugin:
>
>         Options include LDAP using JNDI directly, but then i need to
>         specify the
>         LDAP configuration details. Even if i use JNDI directly, it would be
>         nice to be able to re-use the openam ldap configuration.
>         Optimally, it
>         would be nice to use openam's pre-existing LDAP code for ad-hoc
>         searches, and not have to manage JNDI directly.
>
>         Cheers
>         Brett
_______________________________________________
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Loading...