[keycloak-dev] portal identity experiences

Marek Posolda mposolda at redhat.com
Mon Sep 16 15:22:20 EDT 2013


On 16.9.2013 19:24, Bill Burke wrote:
>
> On 9/16/2013 11:51 AM, Boleslaw Dawidowicz wrote:
>> On Sep 16, 2013, at 3:09 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>>>> We have some. Which aspect are you interested in? Majority of
>>>> deployments are around integrating MSAD - as majority of organizations
>>>> just inherit it as part of Windows Domain.
>>>>
>>> They used portal as an identity broker to MSAD?  What did they use MSAD
>>> for?  User metadata and credentials?  Or was application security
>>> metadata in their too?  (roles/role mappings).
>> No identity broker. Mainly there were two use cases
>> - LDAP integration. MSAD is still most popular one. Major requirement is around authentication and being able to tied roles membership store there with security. All sorts of LDAP schema shapes involved.
> So, Portal *WAS* a broker using MSAD as storage.
>
>> - SSO integration with already deployed frameworks. Most popular are Web SSO solutions. Then there is SAML for more specific cases. Using JAAS always helped as it allowed easily plugging in custom solutions
>>
> Portal as the central auth SSO server?
>
In most of scenarios, we want to authenticate users into portal with 
usage of some other SSO framework (CAS, JOSSO, OpenAM). So portal itself 
is not auth SSO server, but SSO "consumer".

However for integration with Picketlink, we leverage SAML2 protocol and 
we support portal to act on both sides. So portal can act as SAML2 IDP 
(defacto SSO server) or as SAML2 SP (consumer of SSO provided by SAML2 
IDP, which could be another instance of portal or some other completely 
different web application)

Marek


More information about the keycloak-dev mailing list